TLS handshake failing on 2/3 servers

[bananaphone69 0]

Hi,

Long-time AirVPN user, I'm on a linux PC, using the ufw/network-manager/ovpn config file method described here (https://airvpn.org/forums/topic/9148-prevent-leaks-with-ubuntu-linux-gufwufw-thanks-to-worric/) and here (https://airvpn.org/topic/5586-prevent-leaks-with-linux-firestarter-also-stop-traffic-when-vpn-drops/?p=14095). In the last few weeks I have noticed some servers will not go past the TLS handshake stage on most websites but some will. I attach below the results of curl -vL www.startpage.com from a functioning and non-functioning server, namely Libra and Hercules, both in Atlanta Georgia, US UDP 443 entry3, as recommended. I assume this is a global issue but may not be impacting everyone as most will be using Eddie or other tools. If there are other diagnostics that I should attempt, please let me know and I will post results.

Libra Hercules

[bananaphone69 0]

Further update on this. I have tested all available 262 servers and found 90 to be working, 170 to fail at the TLS handshake stage, and 2 inconclusive (Algieba and Chamaeleon, listed as high packet loss and hardware failure on the config generator page). I have attached the list of servers without and with the TLS issue. Would appreciate support from staff or others. In over a decade of relying on AirVPN I've never encountered anything like this.

Without_TLS_issue With_TLS_issue

[go558a83nk 380]

Is this an issue of those sites blocking datacenter IP ranges or known VPN servers specifically?

[bananaphone69 0]

Thanks for your reply. The issue appears to be generalized (across almost all websites) and sudden enough (starting a week or two ago) that I would expect it's not that type of blocking. For instance, I can reproduce the error in ipleak.net and airvpn.org which naturally shouldn't be hostile to AirVPN servers. But if there is a different website or diagnostic you'd like me to try, I can do that. I can also confirm these servers are working okay on systems where I am not using this ufw/network-manager/ovpn config file method.

[Staff 10381]

11 hours ago, bananaphone69 said:

I can reproduce the error in ipleak.net and airvpn.org which naturally shouldn't be hostile to AirVPN servers. ... can also confirm these servers are working okay on systems where I am not using this ufw/network-manager/ovpn config file method.

Hello!

Please note that the TLS handshake and anything else is performed by and between your system and the final web (or other service) servers. The VPN server is not a part of this process. Of course airvpn.org and ipleak.net do not block AirVPN servers. We would rather suspect some MTU related problem. Try to add in your OpenVPN configuration the following directive:

mssfix 1280

Can you also test, in the problematic system, a connection by running OpenVPN directly and not relying on the network-manager-ovpn plugin? In the past it caused several different problems and it was deprecated. If the problem persists please test with ufw completely disabled.
 

Quote

I can also confirm these servers are working okay on systems where I am not using this ufw/network-manager/ovpn config file method.

Do you mean that the problem doesn't appear at all on different systems using the same OpenVPN connection mode (entry-IP address, port and protocol)?

Kind regards
 

[bananaphone69 0]

Hi, thanks for your prompt and helpful response. I will respond to your points in reverse, if that's okay.

1. On some devices I have the ufw/network-manager/ovpn config setup. All of them started failing on certain addresses around one week ago. On a different device where I use wireguard with port 1637, entry3, UDP, I have not had issues with any servers. I can also make an attempt with Eddie or other tools for comparison if that would help.

2. With or without ufw, I was not able to connect to any servers via openvpn CLI.

3. I added mssfix 1280 to the config file for Hercules (a problematic server) and it worked without issue. Adding the same to Libra (a non-problematic server) made no change and it still continues to function as normal. Failing all else, I can add this to all the config files and it should work but I don't understand why this has suddenly happened when I have made no change on the files on my side and about one third still work as normal without the additional mssfix line.

Are there other diagnostics or fix attempts that would help clarify the issue?

[Staff 10381]

21 minutes ago, bananaphone69 said:

3. I added mssfix 1280 to the config file for Hercules (a problematic server) and it worked without issue. Adding the same to Libra (a non-problematic server) made no change and it still continues to function as normal. Failing all else, I can add this to all the config files and it should work but I don't understand why this has suddenly happened when I have made no change on the files on my side and about one third still work as normal without the additional mssfix line.

Are there other diagnostics or fix attempts that would help clarify the issue?

Hello! We're very glad to know that the problem is solved.

From the OpenVPN manual:
 

Quote

--mssfix args

Valid syntax: mssfix max [mtu] mssfix max [fixed] mssfix

Announce to TCP sessions running over the tunnel that they should limit their send packet sizes such that after OpenVPN has encapsulated them, the resulting UDP packet size that OpenVPN sends to its peer will not exceed max bytes.  The default value is 1492 [bytes, ndr]
 

 

Since mssfix 1280 resolved the problem, a plausible explanation that comes to mind is that before the problem started your network had frames fitting the previous MTU, and this is no more possible now So, it could be a change on your ISP side.

Kind regards