Solved OpenVPN not working with UDP anymore; TCP works

[Marc Aronson]

Update: See post #7, below, for the solution.

After about a year of successfully using the OpenVPN Server on my Asus Merlin RT-AX86U router with both my OpenVPN Windows and Android clients, it suddenly became very unreliable / barely working. To be more specific:

• One out of the 4 IP cameras on my network was accessible. I could browse to its login page & watch live video on Tinycam. The other 3 were not accessible.
• I could not successfully browse to my router's login page.

It was interesting to watch the browser attempt to load the login page for the devices that I am characterizing as "not working". It seemed like it was getting some data base from the device's web server, but not enough to actually build the page.

After many experiments I was able to get things working again by changing the protocol from UDP and TCP on both the server and client side.

For completeness, I believe there were 2 changes that happened between the last time I am certain it worked with UDP and when it stopped working:

• I upgraded my router to version 3004.388.4. I did do a full factory reset both before and after the upgrade and reconfigured from scratch.
• Comcast did some upgrades to the network that resulted in my having higher download speeds.

This leads to my 3 questions:

• I understand that UDP prioritizes speed over reliability, but this seems extreme. Does anyone have any idea why UDP no longer works reliably for me?
• Is anyone else experiencing this problem?
• Will using TCP cause any problems if I am trying to access the OpenVPN server from out of the country? I live in California and there are times I need to access it from Europe and India.

Thank in advance for any insights you can provide!

Marc

 

[ColinTaylor]

UDP is dependant on having a good quality network connection. So if you're using mobile internet over a poor link you will have problems (which TCP can compensate for).

What sort of internet connection are you testing this with?

 

[Marc Aronson]

UDP is dependant on having a good quality network connection. So if you're using mobile internet over a poor link you will have problems (which TCP can compensate for).

What sort of internet connection are you testing this with?

Thank you for replying.

On my phone, connected via cellular network. 4G LTE connection.

Same problem when using guest wifi at various locations.

Strange is that it used to work and that now it only works with that one IP camera.

 

[ColinTaylor]

Strange indeed. What is your internet upload speed at home? Perhaps you are saturating your upload capacity.

 

[Marc Aronson]

Strange indeed. What is your internet upload speed at home? Perhaps you are saturating your upload capacity.

That was a good question, but it's not the issue. I get about 800 down and 24 up.

Your question caused me to wonder about QOS, but disabling QOS did not solve the problem either.

Part of me says I should just be happy now that I have it working again by using TCP.

The other part of me says, "Keep digging -- you're going to learn something!"

Marc

 

[Viktor Jaep]

That was a good question, but it's not the issue. I get about 800 down and 24 up.

Your question caused me to wonder about QOS, but disabling QOS did not solve the problem either.

Part of me says I should just be happy now that I have it working again by using TCP.

The other part of me says, "Keep digging -- you're going to learn something!"

Marc

You've got my vote for breaking it, so you can learn something, so you can then share it with the rest of the community.

 

[Marc Aronson]

Updated about 30 mins after my initial post.
Updated 9/6/2023. Successful mssfix size depends on the network.

OK, I've learned some more and I have UDP working again.

Adding the directive "mssfix 1400" in the client ".ovpn" file solves the problem.

On some networks you can increase it to "mssfix 1452", which will be a bit more efficient if it works. If it fails, you can revert to "mssfix 1400".

Below are links to the various postings and articles I read that pointed me at this solution.

If I am understanding correctly, it appears to be an issue with devices trying to send packets across the VPN that exceed the maximum packet size (MTU) that is usable after accounting for the overhead of the VPN.

As you read my next paragraph, keep in mind that while the VPN tunnel is UDP, the traffic traversing the VPN tunnel can be either UDP or TCP.

TCP-based network devices are supposed to automatically deal with resizing their packets if transmission fails due to exceeding the max MTU size. I am guessing that the one camera that is working for me is the only device on my network that actually implements this logic properly. That would explain why it works and the rest don't.

I will probably do a bit more research, but for now, I think I'm going to declare victory.

Marc

https://community.openvpn.net/openvpn/wiki/271-i-can-ping-through-the-tunnel-but-any-real-work-causes-it-to-lock-up-is-this-an-mtu-problem

Setting correct MTU for OpenVPN | Magento Hosting by Sonassi

www.sonassi.com

There were a few others, but these are the most useful 2.

 

[Marc Aronson]

OK, I did some more experimenting and some more reading and I've learned some more.

Based on what I have read, the VPN overhead is 28 bytes on an IPV4 network and 48 bytes for an IPV6 network.

I just ran an experiment and setting "mssfix 1452" works, but "mssfix 1453" doesn't. MTU is set to 1500, which implies that I am operating with 48 bytes of VPN overhead.

Update: I just reviewed my client logs. When I connect via TCP, it's an IPV4 connection.

When I connect via UDP, it's a UDP6 connection.

My guess is that the default OpenVPN configuration doesn't configure things correctly for the 48-byte overhead that happens when using UDP6.

The two possible reasons it used to work:

• Something changed in the OpenVPN upgrades.
• Comcast sent me a note recently that they upgraded the speeds in my area. They may have also introduced a change that resulted in OpenVPN using UDP6 instead of UDP4.

Marc