Routine OpenVPN Test Unsuccessful Today

My computer ‘Phoenix’ does not just act as my Web-server. It also hosts a secure VPN which I own on my own LAN, and that uses the OpenVPN protocol.

Because certain software receives updates from time to time, I also test this VPN from outside my LAN from time to time. To do that, I have typically walked to a certain WiFi Hot-Spot and tested it from there.

However, when I tried this today, I was not able to establish a secure connection to my OpenVPN server at home. The message which I was getting, on my client, was

‘‘

Which finally led to the message

‘‘

And in my server log the messages were:

 


Mon Jan 30 13:16:38 2017 70.24.177.137:61346 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jan 30 13:16:38 2017 70.24.177.137:61346 TLS Error: TLS handshake failed


 

I understand what these error messages mean. When certain Internet traffic is being routed or -ed, it is routine that the return address of individual packets is changed. However, in this case it means that the router policies of the WiFi Hot-Spot I have been able to use in the past has changed, so that I will no longer be allowed to connect to my home VPN in this way.

I find this to be a shame.

(Edit 01/31/2017 : As of the next day, I was able to turn this result into a full success. )

This does not mean that anything is necessarily wrong with the IP address subnet of the VPN I have created on my LAN, because while connecting to the server from outside, the client never gets to create a virtual ‘‘ device, which might have an unsupported subnet if it was created. The process just never passes the -phase, which is meant to create a secure connection between the client and server.

(Edit 01/31/2017 : Since the latest news states that I was able to access my VPN and its member computers, this confirms instead, that the IP Address Subnet of the is fully functional, that remaining 192.168.2.129 / 255.255.255.192 . )

So in the future, I will not be using this WiFi Hot-Spot anymore, especially since their policy could be altered further, into telling the client that a secure connection exists, with properly-routed packets, but a Man-In-The-Middle Attack could be unleashed. And in that case, it would be unfortunate if the client did not possess the logic to conclude, that a secure connection was not established.

Dirk

BTW: When somebody mounts a man-In-The-Middle Attack against a connection secured via Public-Key Cryptography, the latter being based on the premise that any public key which was signed by an arbitrary Certificate Authority, must be a valid key, one trick which does get used, is to respond to a connecting client by mimicking a known public key that is already in-use. So an MiM attack method that is known, will effectively throw the packets back at the client seeking to connect, which some client has already proven, must have legitimate keys. Only, the trick would be to modify the packets somewhat, so that instead of only talking to himself, the client unknowingly ends up talking to the attacker – in a way the attacker can decipher.

 

Routine OpenVPN Test Successful Today

On my Home LAN, I host a VPN. Contrarily to what the term might suggest, “OpenVPN” does not stand for a VPN which is Open, nor which anybody might have access to for free. OpenVPN is just one possible protocol for implementing VPN, and is stuffed to the gills with security measures and encryption, which keep unauthorized people out, and which ensure the privacy of the VPN tunnel, which a Client can invoke from outside the LAN, into the LAN.

I possess an OpenVPN client for my Tablet, that receives updates from its developers from time to time. After several updates to the app, I need to test whether it still works, even if at that moment there is no practical need for me ‘to VPN into my LAN’. And just today I found, that indeed this Android app, as well as my server at home, still work 100%.

In order to verify that I have meshed adequately with my LAN, I typically make it a part of the test to ping a computer on that LAN, which is not itself the VPN Server, and to make sure that I get normal ping responses. This also tells me that my specific routing implementation works, beyond the VPN tunnel to the Server itself. My average ping time today was 37 milliseconds.

A VPN is not really a Proxy. If I wanted to change certain settings, I could redirect all my traffic to the Internet at large, through my VPN at home, which is currently still configured to be routed directly from where my Client is located. I was performing my test from a public WiFi hot-spot, so my regular Internet access was still taking place directly from there.

And, because my Home LAN is located in the same jurisdiction as that WiFi hot-spot was, there would also be zero benefit, to my redirecting all my Internet traffic through the VPN, because doing so would gain no special access privileges, geographically, to Internet content anywhere.

Continue reading Routine OpenVPN Test Successful Today