- This topic is empty.
September 25, 2009 at 2:03 pm #41938
I have a vpn link between 2 Soekris 5501-70’s running zsbeta12.
Link speeds are 4mbs.
The ping times between the units across the link is around 25ms.
Just what is expected.
If I ping devices on each side of the vpn tunnel, I get 46ms if there is little traffic, but get 900-1024 ms if there is traffic (700kbs).
The cpu’s on each 5501 are running around 96% idle.
The results are about the same if encryption is on or off.
I have a bridge to the VPN on each side.
Did I do something wrong in the setup to incur such a high delay cost ?
Any advice is appreciated.September 25, 2009 at 4:38 pm #48801
Try to prioritize the icmp traffic in QoS to make sure packets are not delayed.
Are you definitely sure the tunnel can handle 4Mbps? Could something else utilize the ethernet interface that tunnel goes through?September 25, 2009 at 5:39 pm #48802
The ethernet interface specified for the tunnel only allows the traffic for the vpn tunnel and admin interface traffic – nothing else.
I have tested the link the vpn uses – and usually get about 3-4 mbs.
If fact, when I make a change and first bring up the link, the ping times I get are around 40ms – then as traffic over the vpn resumes, the ping times drop to 700-1000 ms.
Other traffic across this link shows the same effect – poor response to interactive traffic – sluggish response.
QOS for icmp won’t help everything else. I need to get the packet delays through the vpn down to the 40-50 ms range.September 25, 2009 at 6:21 pm #48803imported_fulvioParticipant
Is the VPN compression by LZO enabled? I noticed that compression slow down the VPN bridging.
FulvioSeptember 25, 2009 at 6:27 pm #48804
I am not using compression. I have even turned off encryption.
No improvement.September 25, 2009 at 7:14 pm #48805
QOS for icmp won’t help everything else. I need to get the packet delays through the vpn down to the 40-50 ms range.
It looks like either the link capacity is not always 3-4Mbps, or more traffic passes through the vpn tunnel than you think it does.
As suggested for troubleshooting reason try to apply QoS on icmp and keep pinging. If the problem is fixed, apply QoS on any flow you wish to prioritize.September 26, 2009 at 2:57 pm #48806
I’ll try to put in a network diagram to show the configuration:
Internet-FW–Net A —SK1
Network B is a physical transport for a vpn connection of Net A to Net C.
SK = soekris 5501 fw’s running zsbeta12. A VPN tunnel has been established between the 2 5501’s, with a bridge on each SK1 to the VPN.
Traffic is measured by MRTG on the SK’s bridges and found to average 700kbs.
The routing has been set up so that any internet access on Net C goes to Net A, then out from Net A’s internet access. A download test from a PC on Net C shows a throughput of 2.1mbs. Ping from a pc on Net A to a pc on Net C through the VPN is about 700-1000ms, depending on traffic over the VPN. If there is little traffic on the vpn, this ping test shows about 40ms. A ping from SK1 to SK2 over Net B (therefore not through the vpn tunnel) consistently shows about 20-30 ms (no matter what traffic load over the vpn tunnel) – which is the expected delay through Net B.
I have to reduce the delay cost of the vpn down to 50ms or so.
Hope this info helps.September 28, 2009 at 3:09 pm #48807
Apply a QoS on the VPN interface to see if this will increase the response time on your critical applications. It looks like the link capacity is not fully utilized since the physical interfaces communicate with a stable ping.October 4, 2009 at 6:02 pm #48808
I changed my configuration to a routed environment between eth0 (local net interface on both zeroshell firewalls) and vpn00 which talks to the opposite zeroshell firewall. I implemented QOS on routed packets only.
Again, pinging eth1 to eth1 (wan interface to wan interface on the zeroshell firewalls), I get 23 ms. Pinging anything through the vpn yields 900-1000ms!
I appreaciate any other ideas.
Would it be better to configure the QOS in a bridged network ???
(eth0 and vpn0 bridged) ?October 5, 2009 at 9:44 am #48809
Did you apply the QoS on the ETH01 interface or on the VPN00 interface?
I would suggest to leave the interfaces in routed mode.October 5, 2009 at 3:09 pm #48810
I applied the QOS to the VPN00 interface, not the ETH01 interface.
I did leave things in routed mode.
By the traffic shaping graphs, it appears that the QOS is at least seeing the different classes of traffic I set up, but this didn’t help the ping delay at all.
I had set the icmp in the high priority category, but still am getting 500-1000 ms ping times over the vpn. 😥October 5, 2009 at 8:39 pm #48811
Last but not least try to connect the two boxes back to back with an ethernet cable to have plenty of bandwidth in order to rule out the possibility of a provider issue.October 5, 2009 at 10:15 pm #firstname.lastname@example.orgMember
I don’t think this is the issue because if I ping the default router just outside the vpn tunnel on the far end, I get 430ms over the vpn tunnel. If I ping the wan ip on the far end, I get 22 ms.October 6, 2009 at 7:22 am #48813
Just to make sure.
- You must be logged in to reply to this topic.