No VPN connections using UDP port 53

[viprnet]

It seems to me that something is blocking VPN connections through UDP port 53 for me.

I tested four different servers using UDP but could only connect to openvpn.nl.01.shellfire.net which is at port 80 while the others are at port 53:

Code: Alles auswählen

$ grep openvpn /etc/openvpn/*/client.ovpn
/etc/openvpn/openvpn.be.01.shellfire.net/client.ovpn:remote  openvpn.be.01.shellfire.net 53
/etc/openvpn/openvpn.de.13.shellfire.net/client.ovpn:remote  openvpn.de.13.shellfire.net 53
/etc/openvpn/openvpn.nl.01.shellfire.net/client.ovpn:remote  openvpn.nl.01.shellfire.net 80
/etc/openvpn/openvpn.nl.03.shellfire.net/client.ovpn:remote  openvpn.nl.03.shellfire.net 53

I can connect to the other servers using TCP, so that brings me to the conclusion something is blocking UDP port 53.
In openvpn I see that the TLS negotiation fails:

Code: Alles auswählen

20:33:10 2017 TLS: Initial packet from [AF_INET]151.236.14.50:53, sid=87a11559 c867a052
20:33:10 2017 VERIFY OK: depth=1, C=DE, L=Frankfurt am Main, O=www.shellfire.de, CN=www.shellfire.de CA, emailAddress=hosting@shellfire.de
20:33:10 2017 VERIFY KU OK
20:33:10 2017 Validating certificate extended key usage
20:33:10 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
20:33:10 2017 VERIFY EKU OK
20:33:10 2017 VERIFY OK: depth=0, C=DE, L=Frankfurt am Main, O=www.shellfire.de, CN=server, emailAddress=hosting@shellfire.de
20:34:10 2017 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
20:34:10 2017 TLS Error: TLS handshake failed

wireshark shows that first about 70 packets are exchanged via-via through port 53, then TLS is started and after a New Session Ticket and 11 Application Data packets, the server sends and Encrypted Alert and the TCP connection is dropped.

Any idea?

[Max]

Hello,
it could be that your internet service provider or your network administrator is blocking UDP traffic to port 53. Your router could also be the one who's blocking, you might be able to fix this in the router configuration.

There is not really anything we can do about this besides recommending you to switch to either TCP or using a server that is not listening on port 53.

[viprnet]

Port 53 is not completely blocked, first about 70 packets are exchanged via-via through port 53 and only then TLS fails.

I checked my ADSL modem but could not find any filter that would drop packets after the first "70" packets, so I think this is some kind of denial-of-service filtering done by my ISP (KPN network in Holland).

I think it is a bit strange to use port 53 which is the registered port for DNS and port 80 that is reserved for HTTP, why not use port 1194 which is reserved for OpenVPN? Likely it is because of perceived advantages in less free countries or networks but I can not imagine the network operators there are not monitoring for UDP port 53 originating from the client.

I can live with TCP, speed is not top priority to me, would be happy though if the port is changed or that an additional port is made available (two separate OpenVPN server instances)

[Max]

There are indeed a number of DDoS attacks that some isps are trying to prevent by doing stuff like that even if that's quite problematic in many ways.

We use port 53 on most of our servers because it's an easy fix for many networks where UDP is generally blocked and it also works in 99% of the other cases. We don't use the standard port 1194 since it makes it really easy to specifically block OpenVPN traffic which many network admins like to do. Currently, we do not have the possibility to run multiple instances with different ports but we'll try to have this feature at some point in the future since you're not the first user to request it.

[viprnet]

Thanks for the feedback, makes sense.

I am a bit disappointed in the technical abilities of ISP's if they can block port 1194 but they can not block traffic to the clients with destination address 53, but yes, it is a tiny bit more difficult.