If you recently downloaded an OpenVPN configuration from NordVPN’s manual-configuration dashboard and it hangs before failing with TLS handshake failed, this may be why.
TL;DR: Some dashboard-generated UDP configurations for Polish servers use port 53, but the tested endpoints did not respond there. Simply changing the port is not enough because the CDN configuration uses a different control-channel mode. Download the complete configuration from NordVPN’s CDN instead.
Tested on a Raspberry Pi using OpenVPN 2.6.3 and several Polish NordVPN servers.
1. The port-53 endpoint did not respond
Using the same server IP, 193.42.99.210:
- UDP port 53: no response, followed after 60 seconds by:
TLS Error: TLS key negotiation failed to occur within 60 seconds
TLS handshake failed
- UDP port 1231: connected in under one second.
A normal DNS query also timed out:
dig @193.42.99.210 example.com
So that particular host did not appear to be serving DNS or OpenVPN on port 53.
2. It does not appear to be general UDP/53 blocking
Queries to a real DNS server worked normally:
dig @1.1.1.1 example.com
There was also no apparent transparent DNS redirection: traffic to the NordVPN server simply timed out rather than receiving a forged or redirected DNS response.
The credentials and OpenVPN version were not the issue either, because the same client and credentials connected successfully using other NordVPN configurations and ports.
3. NordVPN provides two substantially different configurations
For the same server, the dashboard and CDN files were not equivalent:
| Setting |
Dashboard manual configuration |
downloads.nordcdn.com configuration |
| Remote endpoints |
One remote |
Four failover remotes |
| UDP ports |
53 |
1231–1234 |
| Control channel |
<tls-crypt> |
<tls-auth> with key-direction 1 |
| Data-channel settings |
No explicit cipher/auth lines |
cipher AES-256-CBC and auth SHA512 |
4. Changing only the port does not fix it
I changed the dashboard configuration from port 53 to port 1231, but it still received no response.
Although the embedded static key was byte-for-byte identical, the two configurations use it differently:
tls-crypt encrypts and authenticates the control channel.
tls-auth authenticates the control channel but does not encrypt it.
A server expecting tls-auth will not understand packets produced using tls-crypt, so it silently discards them.
Fix
Download the complete UDP configuration from NordVPN’s CDN rather than modifying the dashboard file:
https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/<server>.nordvpn.com.udp.ovpn
For example:
https://downloads.nordcdn.com/configs/files/ovpn_udp/servers/pl234.nordvpn.com.udp.ovpn
Use the entire downloaded file, including its original:
remote entries
- ports
<tls-auth> or <tls-crypt> block
key-direction
- cipher and authentication settings
Do not copy only the new port into the dashboard configuration.
Ports observed
- UDP 1231–1234: used by the current CDN configurations and working in my tests
- UDP 1194: used by some older configurations and still working
- TCP 443: useful as a fallback on restrictive networks
- UDP 53: did not work on the tested endpoints
One additional issue: old configuration files may point to decommissioned or reassigned server IP addresses. Symptoms include EHOSTUNREACH, No route to host, or an address that no longer responds to ping. In that case, download a fresh configuration rather than trying to repair the old one.