It has come to my attention that there exists an idiosyncrasy in the way the Modem/Router of my ISP works, the new modem I was just given, which can lead other Bell customers to confusion.
In its port-forwarding rules, we can select whether we would like to forward a TCP port, a UDP port, or Both. People may habitually choose Both, maybe even because we do not remember which protocol we are using, only which port number it listens on.
If the LAN-computer is only listening on the corresponding UDP port, and we have told this router to forward Both, then an external port scan will tell us, that Both Ports Are Closed. This is because the corresponding TCP port on the LAN machine Is Closed, and because UDP ports generally do not have to report back, when they receive packets. UDP ports are stateless.
Thus, If some people have naively set up an OpenVPN server to listen on the UDP port, but have told the router to forward Both port-types, and if they then try to connect, the failure of the server to respond could have several reasons. But then, if those users ask an external port-scanner to give them the status of the WAN port, the scanner will tell them that the port is closed, and the users may jump to the conclusion, that they are being blocked on the side of the ISP, because obviously, the dedicated port-scanning site would not be blocking them, for the purpose of testing whether their WAN port is in fact listening.
I have just done the following experiment:
- I have changed the configuration of my OpenVPN server to listen on the TCP port instead – as if I was switching from a UDP to a TCP -based VPN.
- I have told my router to forward only the TCP port.
- I have asked the port-scanner to scan the port.
In that situation, the port-scanner tells me that the port is Open – Available!
Now, If my ISP was in fact blocking port 1194 – UDP , would they not also want to cover the possibility, that I could be using a TCP-based VPN, and block 1194 – TCP as well?
Yet, using port 1194 – UDP , I cannot connect to my VPN from the public WiFi Hot-Spot. It would seem to follow, that it is the public WiFi Hot-Spot blocking me, and not the ISP.
But in general, when trying to diagnose OpenVPN issues, there is an added aspect to how this protocol can be set up to work, which can interfere with a diagnosis. We can choose to have every packet signed using a static key. This static key does not encrypt anything, it just signs every packet. The way my VPN server is set up, if the signature is invalid, the packet gets dropped like a hot potato. Nothing is done to acknowledge it ever existed.
The advantage of this is, it thwarts brute-force attacks, as well as attempts to cause buffer-overrun errors, etc..
If the protocol is TCP, the socket still acknowledges the packet, because that is built into TCP at the kernel-layer. But if the protocol is UDP, then the situation mimics what would happen, if the port was just swallowing everything, but because there is an error in the static key. Also, a port-scanner will time-out, because its packets are unsigned.
So how do I know that there is no error in my static key, between the client and the server? Because the same configuration has worked many times before, and I have done nothing to change it.
So I think I can safely stick to my conclusion, that I was being blocked at the other end. Otherwise, some unlikely change in the client app has affected how the static key is parsed.
BTW: I am noticing that a Windows computer will react differently to how a Linux machine reacts, when a WAN TCP Port is Forwarded to a LAN-machine Port which is Not Listening.
Under Linux, the Kernel immediately responds with a Refusal, while a Windows PC just generally Does Not Respond – Kind of how it is with a UDP Port by default.