- This topic is empty.
August 31, 2009 at 10:26 pm #41900
I seem to be having this problem in a number of Zeroshell deployments I have
We have a few different WAN’s connected using Zeroshell + Netbalancer at the head office, with two WAN connections. Each Branch office then has two VPN connections to each WAN connection at head office (In Each VPN connection at the head office, the appropriate gateway is assigned), and the tunnels are bonded at each end in a Failover configuration.
This is so if either of the WAN connections at head office went down, the branches BOND would fail over VPN traffic to the other and everyone is happy.
What I am finding is:
If I configure the VPN tunnels using TCP, we get very high latency on the VPN tunnels. For example, running a ping over the tunnel to a remote host, it will bounce around from 30ms to 160ms, with very little traffic running over the tunnel. The end users see this in their applications as well, and complain of slow speeds.
If I configure the VPN tunnels using UDP, everything is perfect with ping times constant at around 30 or 40ms (depending on the link). However, I have found that if I reboot the head office router, then these same tunnels that were perfect before the reboot, seem to experience packet loss of about 5-8%. That is, that the same constant ping that was perfect before the reboot, now drops 1 or two pings in every 10 or 20 sent. This too is noticable to the end users, as the connection is ‘pausing’.
Can anyone shed any light on to what may be causing this? I have a few WAN’s out there now that really need a fix on this.
AaronSeptember 7, 2009 at 11:40 am #48710
OK I think I may have figured out what is going on.
I believe the NetBalancer module may be trying to split my traffic out over multiple links, which is why with UDP (connectionless) it is dropping the packet, however with TCP it is re-trying and is getting the packet through, but causing high latency because of the delay.
I definitely have configured the VPN tunnels to use a specific interface through netbalancer.
I was hoping someone, or fulvio, may be able to assist with how Net Balancer should be configured in certain situations.
For example, a scenario where I have a zeroshell at both sites, and two ADSL links of identical speed at both ends, which only purpose will be for a VPN bond to load balance traffic across, how would I have Net Balancer configured? Load Balance + Failover, with both gateways having an equal weight of 1?
Or for example in the configuration where I have a head office with two links, want all outbound traffic to go via one link, and then have a remote branch with a VPN Bond to both links for load balance, would I have the NetBalancer configuration set to Fail Over, with the primary link weighted as 2, with the secondary link weighted as 1, and then the VPN tunnels configured to go out via each link?
This is the configuration I have been trying, with mixed results as mentioned above in regards to packet loss and high latency.
I have tried Beta 11 & Beta 12, thinking that I may have uncovered a bug, but I get the same result in both, and can re-produce my results at different sites, with different links.
In the first example I gave, I have had to remove the bond and go back to a single VPN tunnel using ‘auto’ as the default gateway and only using one link, and when configured as a UDP OpenVPN tunnel, the latency problem does not exist. It only occurs when I move into the Bond / Net Balancer combo does it return.
Hoping someone can shed some light, as I really need to get these networks solved and my bonds completed!
Thanks guys,September 7, 2009 at 11:45 am #48711
Forgot to mention that I even went as far as making custom NetBalancer rules to the destination VPN IP to force it out via one link, but it did not help my packet loss issues.
I am still not 100% sure if its NetBalancer moving traffic over the correct gateway properly, or if it is the Bond interface that is not doing something correctly, and that its load balancing module is the thing that is dropping traffic.
- You must be logged in to reply to this topic.