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.

 

Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

The reality is that, being 52 years old and only having studied briefly in my distant past, my formal knowledge in Computing is actually lacking these days, and one subject which I know too little about, is how Push Notifications work. Back in my day, if a laptop was ‘asleep’ – i.e. In Standby – it was generally unable to be woken externally via WiFi, but did have hardware clocks that could wake it at scheduled times. Yet we know that mobile devices today, including Android and iOS devices, are able to receive push notifications from various servers, which do precisely that, and that this feature even works from behind a firewall. And so I can muse over how this might work.

I can think of two ways in which this can hypothetically work:

  1. The application framework can centralize the receipt of push notifications for the client device, to one UDP port number. If that port number receives a packet, the WiFi chip-set wakes up the main CPU.
  2. Each application that wants to receive them, can establish a client connection to a server in advance, which is to send them.

The problem with approach (1) is that, behind a firewall, by default, a device cannot be listening on a fixed port number, known to it. I.e., the same WAN IP Address could be associated with two devices, and a magic packet sent to one fixed port number, even if we know that IP Address, cannot be mapped to wake up the correct device. But this problem can be solved via UPnP, so that each device could open a listening port number for itself on the WAN, and know what its number is.

We do not always know that UPnP is available for every NAT implementation.

Approach (2) requires more from the device, in that a base-band CPU needs to keep a list, of which specific UDP ports on the client device will be allowed to wake up the main CPU, if that port receives a packet.

Presumably, this base-band CPU would also first verify, that the packet was received from the IP address, which the port in question is supposed to be connected to, on the other side, before waking the main CPU.

(Edit 12/19/2016 : Google can simply decide that after a certain Android API Number – i.e., Android version – the device needs to have specific features, that earlier Android APIs did not require.

Hence, starting from , or , Google could have decided that it was no longer a special app permission, for the user to acknowledge, to wake the device. Likewise, starting from some Android version, possessing a base-band CPU might have become mandatory for the hardware, so that the API can offer a certain type of push notification.)

Also, approach (1) would have as drawback, a lack of authentication. Any networked device could just send this magic packet to any other networked device, provided that both the IP address and the port number it is sensitive to are known.

Approach (2) would bring as an advantage, that only specific apps on the client device could be enabled to receive push notifications, and the O/S would be aware of which UDP ports those are sensitive on, so that the base-band CPU would only be waking up the main CPU, if push notifications were received and associated with an app authorized to wake the device.

Also, with approach (2), the mapping of WAN port numbers back to LAN port numbers would still take place passively, through port triggering, so that the WAN-based server does not need to know, what LAN-based port number the connected port is associated with on the client device.

But, approach (2) has as a real drawback, that a server would need to keep a socket open, for every client it might want to send a push notification to. This might sound unimportant but is really not, since many, many clients could be subscribed to one service, such as Facebook. Are we to assume then, that the Facebook server also keeps one connection open to every client device? And if that connection is ever dropped, should we assume that a sea of client devices reconnect continuously, as soon as their clocks periodically wake them?

Dirk

Continue reading Two Hypothetical Ways, in which Push Notifications Could Work Over WiFi

I have a little glitch in my OpenVPN configuration.

One of the subjects which I have written about before, is that I host a VPN, which uses the OpenVPN protocol, and that I have used my own, hand-written configuration files for it.

There are certain ways in which this VPN is atypical, in its configuration. For example, what most system administrators will do, is assign a range of IP addresses on their virtual LAN, which do not overlap anywhere with the IP address range on their physical LAN. OTOH, what I have done is to use the configuration lines:

 


ifconfig 192.168.2.129 255.255.255.128
ifconfig-pool 192.168.2.130 192.168.2.254 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"

 

In my thoughts, I was assigning the IP address range from 192.168.2.129 through 192.168.2.254 to the VPN. But whenever my OpenVPN server starts or restarts it does so with a warning, that this IP address range overlaps with the existing IP addresses of my physical LAN, which go from 192.168.2.0 through 192.168.2.255 .

This is how I made a little mistake: My configuration unwittingly also included IP address 192.168.2.255 in the range, which will be routed as belonging to the VPN. And this is due to the first line above, which simply has 255.255.255.128 as its subnet mask.

This can cause the following problem. As part of my physical LAN, address 192.168.2.255 sometimes serves a purpose. It is the UDP Broadcast address of my router, and can be used by clients to find all the connected LAN clients.

Probably because I have done this, the command ‘nmblookup‘ will not work on my machine ‘Phoenix’, which is also my server (as I discovered for the first time last evening). But beyond that, this could be why setting this server to act as a WINS server creates a failure in the configuration of my LAN. This may not really be due to any intolerance on the part of my Windows 7 machine ‘Mithral’, of a Linux box acting as a WINS server.

Also, the command ‘nmblookup‘ works fine on both the other Linux machines on my LAN: On ‘Klystron’ and on ‘Walnut’.

If I was determined to make my configuration better, I could try tweaking this OpenVPN configuration, let us say with a subnet mask of 255.255.255.192 instead of with 255.255.255.128 . Of course, I would then also have to reduce the number of possible, available connections to my VPN accordingly, let us say so:

 


ifconfig 192.168.2.129 255.255.255.192
ifconfig-pool 192.168.2.130 192.168.2.191 255.255.255.0
push "route-gateway 192.168.2.129 255.255.255.0"

 

In other words, I can create a 6-bit subnet, the addresses of which are prepended by the bits ’10’. However, it was incorrect of me to have a 7-bit subnet, which was simply prepended by the high bit ‘1’, because unfortunately, doing so also masks the UDP Broadcast Address of the router.

For the moment, not being able to use the ‘nmblookup‘ command on ‘Phoenix’ has not had significant consequences for me, and one main reason might be the fact that in general, Linux avoids using NetBIOS. Also, the graphical browser I use, does not seem to depend 100% on this command, or on the local machine being the WINS server, in order to work.

So this error has little urgency for me, and also did not impede my use of the computers.

Dirk

(Edit : ) Minutes after writing this posting, I have applied the change in configuration as described. With great joy, I find that my ‘nmblookup‘ command works fine now.

Now, this error should not strike people as serious, because it was only according to the LAN, as seen by one client (‘Phoenix’) that this address belonged, incorrectly, to the VPN. However, sometimes routers have been programmed in their firmware to offer as an extended feature, to reflect whatever IP address assignments are reported by one client. If mine is such a router, then of course, this one IP address would have been spotted as a conflict, and overridden by the router, so that the other machines on my LAN, continued to see the correct mapping.

Continue reading I have a little glitch in my OpenVPN configuration.