Latest posts by Alvin Bryan (see all)
- Millionaire Tyupkin Malware ATM Hackers May Come to US, India After Hitting Europe - October 23, 2014
- BitLicense Will Allow Bitcoin Spying in New York - October 22, 2014
- Australians are Fighting Data Retention Laws - October 22, 2014
We have noticed some concerns about periodic traffic stalling when using a VPN client over a DSL connection so here is a discussion of the different possible issues involved and how to find out what’s wrong.
Let’s take a look at MTU issues first. A smaller MTU means more packets need to be sent for the same amount of data, increasing the number of round trips. If a ping testing the default MTU of 1500 doesn’t work, check the overhead that your encapsulation generates, and if your VPN is set to “do not fragment bit” to prevent unnecessary retransmission. Also check if a firewall might be disabling ICPM. If your MTU values are all different on your PPPoE DSL link, virtual interface and VPN client defaults, it will be a mess. Check your configuration again as well.
Raw Speed and VPN Client Speed
Next to test would be your raw speed to see if there are speed issues with your VPN client. Try copying files to and from a server using FTP or SCP. If the speed checks out based on your connection, your VPN client is not causing the delays.
Latency may still be a problem, so check your connectivity methods – ADSL, UMTS. UMTS can be about 5 times slower than ADSL depending on your location and server, so take that into account. Some applications like SMB can slow you down, and you may need to apply a solution like DFS-R or Sharepoint. ERP applications that query the database directly will also cause delays because of many round trips, but if you use DIAS-iS you won’t have this problem. If you don’t need to use SMB, an ERP app with servers in multiple sites can work faster.
If you are getting different speeds on your pings over the VPN and not, The QoS of your ISP can also be the culprit. Over a VPN, your ISP may be reading traffic as different protocols, and giving priority to a particular type of traffic. Test this bandwidth shaping using software like MTR, and check where there are latency issues. You might also try using a different port number for your server, or redirecting the port so that the traffic cannot be identified (e.g. as in the example above, use an odd port number instead of 5060 to trick the QoS into identifying UDP as VoIP). If the problem persists, consider changing your ISP.
Modem QoS, TCP and Overhead Delays
Your modem can also be doing QoS, depending on what it’s running (IIRC and Linux are examples). Try updating your firmware, and if this fails, test a different DSL modem and run the tests again.
For OpenVPN users, transport can be the problem, especially for TCP over TCP because of the congestion control mechanisms. Whenever there is mild packet loss, a chain reaction occurs and everything eventually stalls. If this is the case, switch to UDP. There is no error checking, so it’s faster, and the encapsulated TCP takes care of that anyway.
If you are dealing with ATM encapsulated transports, or xDSL lines, look at your overhead. It will be affected by the PPPoE / PPPoA. Check also if your router is handling this, because the VPN client added to this can slow things down. If you still have problems, don’t hesitate to contact ExpressVPN.