cancel
Showing results for 
Search instead for 
Did you mean: 

OpenVPN - traffic-shaped?

N/A

OpenVPN - traffic-shaped?

Hi All,

I use OpenVPN to link my home network (Plusnet) with my workstation at uni (on JANET). Looks like packets over the VPN are being delayed and/or dropped (see pings below).

Is PN's traffic-shaping likely to be screwing things up here?

Well inside my monthly usage quota btw...

Thanks,

Andy


Ping from uni workstation to home, over Plain Old Internet, looks fine:
esemjrpg3 work # ping mascotsquare.plus.com -c 5

PING mascotsquare.plus.com (81.174.170.196) 56(84) bytes of data.
64 bytes from mascotsquare.plus.com (81.174.170.196): icmp_seq=1 ttl=20 time=22.4 ms
64 bytes from mascotsquare.plus.com (81.174.170.196): icmp_seq=2 ttl=20 time=22.9 ms
64 bytes from mascotsquare.plus.com (81.174.170.196): icmp_seq=3 ttl=20 time=29.9 ms
64 bytes from mascotsquare.plus.com (81.174.170.196): icmp_seq=4 ttl=20 time=21.6 ms
64 bytes from mascotsquare.plus.com (81.174.170.196): icmp_seq=5 ttl=20 time=24.3 ms

--- mascotsquare.plus.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 21.652/24.267/29.932/2.966 ms


Ping over the VPN, huge delay and dropped packets:
esemjrpg3 work # ping 192.168.100.1 -c 5                                                                                                  

PING 192.168.100.1 (192.168.100.1) 56(84) bytes of data.
64 bytes from 192.168.100.1: icmp_seq=1 ttl=64 time=820 ms
64 bytes from 192.168.100.1: icmp_seq=2 ttl=64 time=815 ms
64 bytes from 192.168.100.1: icmp_seq=3 ttl=64 time=956 ms

--- 192.168.100.1 ping statistics ---
5 packets transmitted, 3 received, 40% packet loss, time 4000ms
rtt min/avg/max/mdev = 815.155/863.803/956.218/65.377 ms
12 REPLIES
Community Gaffer
Community Gaffer
Posts: 12,955
Thanks: 749
Fixes: 69
Registered: 04-04-2007

OpenVPN - traffic-shaped?

Hi there,

Does a traceroute suggest where the packets are being dropped? VPN traffic is in silver AFAIK and should not be dropped. VPN sessions from my home connection are pretty solid too.

Kind Regards,

Bob Pullen
Plusnet Products Team
If I've been helpful then please give thanks ⤵

N/A

OpenVPN - traffic-shaped?

Hi Bob,

Thanks for the quick reply.

The VPN is a direct link between the two machines, so a traceroute would be pretty pointless. I could post a traceroute of the link outside of the VPN, but this would also be pointless as non-VPN packets are not being dropped or delayed!

Just wanted to check in case OpenVPN had quietly been given a low priority for some reason. I've noticed some of my VPNs behaving like this before and it's gone away after a while, but it's damn annoying when I want to get on with some work!

Guess I'll just wait it out, unless you can think of anything else to try/investigate...?

Thnaks,

Andy
N/A

OpenVPN - traffic-shaped?

What happens if you ping/traceroute the real address of your uni connection rather than the 192.* address created by the VPN?
N/A

OpenVPN - traffic-shaped?

Hi squidgey,

In my original post there's a ping from uni to home using the real addresses - as you can see it's nice and quick (20-30ms)! I'm unable to ping in the other direction due to the campus firewall (simply blocks incomming connections).

The situation has improved slightly now; packets have stopped being dropped although pings are still 200-500ms. (Again, pinging between the real addresses takes around 20ms.) I have done nothing to any of my kit which would have made this improvement, so I'm guessing it's the network; maybe it's become less busy during the evening, so less shaping is in operation.

As there are several very different VPN technologies, I can only think that maybe OpenVPN packets are incorrectly classified as some other type of (lower priority) application on the traffic shaping boxes...
N/A

OpenVPN - traffic-shaped?

It looks like everything is back to normal now; pings over the VPN have returned to 20-30ms. Again, I've done nothing...

Is it possible for a PN techie to look into this; it's not the first time I've experienced this problem and I'm certain the problem isn't with my kit. I'd like to know if my theory about OpenVPN traffic being misclassified is true...

Thanks,

Andy
N/A

OpenVPN - traffic-shaped?

I think the first thing to do would be to find out which ports OpenVPN uses.
N/A

OpenVPN - traffic-shaped?

UDP 1194 is the deafault, tho it's trivial to change both port number and between UDP/TCP.

Does this info really help; I thought the traffic-shaping boxes used deep-packet inspection to classify traffic?
N/A

OpenVPN - traffic-shaped?

If you can, I would change your packet type from UDP to TCP, as UDP is connectionless and subject to being lost, whereas TCP is much more robust. Some routers also drop UDP packets if they are overloaded and give priority to TCP, which may be your problem.
N/A

OpenVPN - traffic-shaped?

There is no reason for a router to drop UDP in favour of TCP during periods of high load; both should have equal priority. (If anything, it makes more sense for TCP to be dropped first, since it can react to congestion much better than UDP).

Thanks for the suggestion, but I shant be changing to TCP as this will generally degrade perfomance of VPNs.

Looks like Customer Support has lost interest in this thread; time to raise a ticket...
Plusnet Alumni (retired) _CN_
Plusnet Alumni (retired)
Posts: 385
Registered: 11-06-2007

OpenVPN - traffic-shaped?

Quote
UDP 1194 is the deafault


The above is correct for OpenVPN

I just checked your traffic flows and the Ellacoya is marking OpenVPN into the gold queue as designed, HTH.
N/A

OpenVPN - traffic-shaped?

Hi Carl,

Thanks for replying - I was getting in a rage trying to fight the "raise a ticket" system!

For my peace of mind, could you give a few more details about how the Ellacoya told you this information? Is 'OpenVPN' defined as an 'application', which is placed into the gold queue, or is there a more generic 'VPNs' application group? Whilst I'm certain OpenVPN is configured be classed as a VPN (and hence gold), I'm still sceptical that maybe the Ellacoya is incorrectly identifying my OpenVPN packets as some different application (maybe a P2P app)?

Would you agree with me that the symptoms I experienced in my original post were characteristic of traffic-shaping *somewhere* between my two machines? What else would cause such as selective dropping/delaying of packets?

Thanks,

Andy
Plusnet Alumni (retired) _CN_
Plusnet Alumni (retired)
Posts: 385
Registered: 11-06-2007

OpenVPN - traffic-shaped?

Hi Andy

Please capture some packets while only running OpenVPN during a period where you are having poor performance. Take a look at the ToS value in the IP header for downstream packets and check that it is = 80 (HEX). You can PM me the capture if you'd like me to check for you.