Vpn latency

Routing & Switching Network Services
1

Hi,
Can you help me to understand this behavor.

I have one server with openvpn client installed e connected to the openvpn server in HQ in another location.

Untitled Diagram(1)

Everything works, but when I try to reach the remote server, the connection has a high latency for a couple of seconds ( 20-30 sec), after that it start working correctly.

 $ ping 10.0.8.10
PING 10.0.8.10 (10.0.8.10) 56(84) bytes of data.
64 bytes from 10.0.8.10: icmp_seq=1 ttl=63 time=2127 ms
64 bytes from 10.0.8.10: icmp_seq=2 ttl=63 time=2000 ms
64 bytes from 10.0.8.10: icmp_seq=3 ttl=63 time=1632 ms
64 bytes from 10.0.8.10: icmp_seq=4 ttl=63 time=1292 ms
64 bytes from 10.0.8.10: icmp_seq=5 ttl=63 time=1247 ms
64 bytes from 10.0.8.10: icmp_seq=6 ttl=63 time=1293 ms
64 bytes from 10.0.8.10: icmp_seq=7 ttl=63 time=1520 ms
64 bytes from 10.0.8.10: icmp_seq=8 ttl=63 time=2454 ms
64 bytes from 10.0.8.10: icmp_seq=9 ttl=63 time=2707 ms
64 bytes from 10.0.8.10: icmp_seq=10 ttl=63 time=2320 ms
64 bytes from 10.0.8.10: icmp_seq=11 ttl=63 time=2244 ms
64 bytes from 10.0.8.10: icmp_seq=12 ttl=63 time=2165 ms
64 bytes from 10.0.8.10: icmp_seq=13 ttl=63 time=1892 ms
64 bytes from 10.0.8.10: icmp_seq=14 ttl=63 time=1752 ms
64 bytes from 10.0.8.10: icmp_seq=15 ttl=63 time=2054 ms
64 bytes from 10.0.8.10: icmp_seq=17 ttl=63 time=1915 ms
64 bytes from 10.0.8.10: icmp_seq=18 ttl=63 time=2059 ms
64 bytes from 10.0.8.10: icmp_seq=20 ttl=63 time=2072 ms
64 bytes from 10.0.8.10: icmp_seq=21 ttl=63 time=2081 ms
64 bytes from 10.0.8.10: icmp_seq=22 ttl=63 time=2237 ms
64 bytes from 10.0.8.10: icmp_seq=23 ttl=63 time=1844 ms
64 bytes from 10.0.8.10: icmp_seq=24 ttl=63 time=1271 ms
64 bytes from 10.0.8.10: icmp_seq=25 ttl=63 time=457 ms
64 bytes from 10.0.8.10: icmp_seq=26 ttl=63 time=513 ms
64 bytes from 10.0.8.10: icmp_seq=27 ttl=63 time=487 ms
64 bytes from 10.0.8.10: icmp_seq=28 ttl=63 time=595 ms
64 bytes from 10.0.8.10: icmp_seq=29 ttl=63 time=381 ms
64 bytes from 10.0.8.10: icmp_seq=30 ttl=63 time=730 ms
64 bytes from 10.0.8.10: icmp_seq=31 ttl=63 time=961 ms
64 bytes from 10.0.8.10: icmp_seq=32 ttl=63 time=793 ms
64 bytes from 10.0.8.10: icmp_seq=33 ttl=63 time=65.6 ms
64 bytes from 10.0.8.10: icmp_seq=34 ttl=63 time=62.7 ms
64 bytes from 10.0.8.10: icmp_seq=35 ttl=63 time=64.0 ms
64 bytes from 10.0.8.10: icmp_seq=36 ttl=63 time=61.4 ms
64 bytes from 10.0.8.10: icmp_seq=37 ttl=63 time=64.2 ms
64 bytes from 10.0.8.10: icmp_seq=38 ttl=63 time=62.8 ms
64 bytes from 10.0.8.10: icmp_seq=39 ttl=63 time=65.4 ms
64 bytes from 10.0.8.10: icmp_seq=40 ttl=63 time=63.0 ms
64 bytes from 10.0.8.10: icmp_seq=41 ttl=63 time=71.9 ms
64 bytes from 10.0.8.10: icmp_seq=42 ttl=63 time=74.1 ms
64 bytes from 10.0.8.10: icmp_seq=43 ttl=63 time=355 ms

What is the reason of this behavor?

Thanks

2

Hello Giovanni

This is behaviour that we often see when pinging a device that has just come up, or when pinging over a network where devices are “busy doing other things”. You will usually see this if the destination device (router, server, switch, PC, anything) you’re pinging has just been booted up. During this time, it is busy doing other things like loading memory, sending and receiving data, and more. This will characteristically cause a delay in responses to pings for several seconds until it gets to a more idle state. Once procedures are complete, it is more readily able to respond to the pings, so you see a gradual decrease in response times.

Now the cause may not be the actual destination device, but the network devices that the ping traverses. This is especially true with VPNs. If the VPN tunnel has just been established, it may take several seconds for negotiations and “housekeeping” procedures to complete between the VPN client and server. This will result in delayed pings, either due to network congestion or more likely, due to processing power of the network devices being taken up by these procedures. As these procedures die down within the device, ping response times will decrease.

Typically, once devices have fully booted up, and once VPN links have been successfully established, ping latency should get back to normal after a few dozen seconds, such as is the case in your output.

Now if you see this behaviour every time you start pinging, even though devices are all booted up and VPNs have been established already, then that is strange behaviour. In such a case, you may have to troubleshoot the device that is being pinged, or the VPN configuration (is it an “on-demand” VPN?).

I hope this has been helpful!

Laz