Please restore "Connect using TCP only" #595

Lukas-UAUX commented 2026年05月18日 15:02:08 +02:00

I am feeling like a broken record here but - please restore the "Connect using TCP only" again. (I already did the same for linux and android where the same thing happended...)

This feature is very important for us to make the VPN usable in networks where the MTU is limited and UDP (that can not fragment packets) wont't work.

This happens in all networks that add additinal headers (like DSLite connections with NAT64) or where a double NAT in some form happens like a plethora of public networks and mobile networks (4G/5G)

Additionally a bunch of public WiFis block UDP outright completely...

Auto-Detection is here not an option as the connection detection will allways be false positve (appears fully connected as the check packets are small enough) and detecting MTU issues is close to impossible

PS: Before this happens on Windows also - do you have a place to note this globally so that this applies to all implmentations?

I am feeling like a broken record here but - please restore the "Connect using TCP only" again. (I already did the same for linux and android where the same thing happended...) This feature is *very* important for us to make the VPN usable in networks where the MTU is limited and UDP (that can not fragment packets) wont't work. This happens in all networks that add additinal headers (like DSLite connections with NAT64) or where a double NAT in some form happens like a plethora of public networks and mobile networks (4G/5G) Additionally a bunch of public WiFis block UDP outright completely... Auto-Detection is here *not* an option as the connection detection will allways be false positve (appears fully connected as the check packets are small enough) and detecting MTU issues is close to impossible PS: Before this happens on Windows also - do you have a place to note this globally so that this applies to all implmentations?

Lukas-UAUX commented 2026年05月18日 15:03:47 +02:00

Ah and no Wireguard is also not an option here as ist suffers from the exact same problem and is incompatible with our network structure.

Ah and no Wireguard is also not an option here as ist suffers from the exact same problem and is incompatible with our network structure.

fkooman commented 2026年05月18日 15:08:27 +02:00

The idea was always that the "online check" would make sure that UDP worked with the configured MTU. Breaking the VPN is unacceptable. The "mitigation", until this online check is fixed, is a button that has a "Switch to TCP", or similar. This button can also be used if the online check takes too long.

What you could do to mitigate this problem somewhat is set the MTU for WireGuard and OpenVPN to a lower value, this is actually recommended even if the online check would work properly:

• WireGuard: https://docs.eduvpn.org/server/v3/wireguard.html#mtu
• OpenVPN: https://docs.eduvpn.org/server/v3/openvpn.html#mtu

The idea was always that the "online check" would make sure that UDP worked with the configured MTU. Breaking the VPN is unacceptable. The "mitigation", until this online check is fixed, is a button that has a "Switch to TCP", or similar. This button can also be used if the online check takes too long. What you *could* do to mitigate this problem somewhat is set the MTU for WireGuard and OpenVPN to a lower value, this is actually recommended *even* if the online check would work properly: * WireGuard: https://docs.eduvpn.org/server/v3/wireguard.html#mtu * OpenVPN: https://docs.eduvpn.org/server/v3/openvpn.html#mtu

Lukas-UAUX commented 2026年05月18日 15:16:23 +02:00

Nice that setting the MTU is now actually possible - that solves a lot of headaches in support for pointing people to the setting.

But as this won't solve all problems can't you do the same as the other implementations in allways showing this "Reconnect with TCP" Button?

As i recall the intention in removing was that users never unset this option which casuses problems so this would be a compromise we could live with - especially as setting the MTU is now possible

Nice that setting the MTU is now actually possible - that solves a lot of headaches in support for pointing people to the setting. But as this won't solve all problems can't you do the same as the other implementations in allways showing this "Reconnect with TCP" Button? As i recall the intention in removing was that users never unset this option which casuses problems so this would be a compromise we could live with - especially as setting the MTU is now possible

fkooman commented 2026年05月18日 15:19:54 +02:00

But as this won't solve all problems can't you do the same as the other implementations in allways showing this "Reconnect with TCP" Button?

This will be there in 4.1.0: #563

> But as this won't solve all problems can't you do the same as the other implementations in allways showing this "Reconnect with TCP" Button? This will be there in 4.1.0: https://codeberg.org/eduVPN/apple/issues/563

Lukas-UAUX commented 2026年05月19日 20:01:04 +02:00

@fkooman Hmm we enabled the MTU setting on our test server - and the value does get put in the ovpn profile - but the server then overrides it with a pushed setting back to 1500.

I did manage to get the desired MTU only by placing pull-filter ignore tun-mtu at the top of the profile so there must be something broken on the server side.

I will try to investigate this further with our server admin but maybe you already have an idea where this push comes from?

@fkooman Hmm we enabled the MTU setting on our test server - and the value does get put in the ovpn profile - but the server then overrides it with a pushed setting back to 1500. I did manage to get the desired MTU only by placing `pull-filter ignore tun-mtu` at the top of the profile so there must be something broken on the server side. I will try to investigate this further with our server admin but maybe you already have an idea where this push comes from?

fkooman commented 2026年05月19日 20:17:35 +02:00

Did you run "apply changes" on the server/node(s)? It is a server setting as well as a client setting...

Did you run "apply changes" on the server/node(s)? It is a server setting as well as a client setting...

Lukas-UAUX commented 2026年05月20日 11:35:51 +02:00

Is this different from the sudo vpn-maint-apply-changes from the documentation?

Is this different from the `sudo vpn-maint-apply-changes` from the documentation?

fkooman commented 2026年05月20日 11:39:29 +02:00

@Lukas-UAUX wrote in #595 (comment):

Is this different from the sudo vpn-maint-apply-changes from the documentation?

No, that's it!

Edit: if it does NOT work for you even after applying changes, perhaps you can open issue in vpn-user-portal repo? It doesn't belong here...

@Lukas-UAUX wrote in https://codeberg.org/eduVPN/apple/issues/595#issuecomment-15401420: > Is this different from the `sudo vpn-maint-apply-changes` from the documentation? No, that's it! Edit: if it does NOT work for you even after applying changes, perhaps you can open issue in vpn-user-portal repo? It doesn't belong here...

Lukas-UAUX commented 2026年05月20日 16:18:59 +02:00

Ah okay it had to be run on every node too (and even when they were rebooted anyway ;-) )

Ah okay it had to be run on every node too (and even when they were rebooted anyway ;-) )