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 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Mon Jan 30 13:16:38 2017 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 / . )

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.


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.


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:


push "route-gateway"


In my thoughts, I was assigning the IP address range from through 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 through .

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

This can cause the following problem. As part of my physical LAN, address 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 instead of with . Of course, I would then also have to reduce the number of possible, available connections to my VPN accordingly, let us say so:


push "route-gateway"


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.


(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.

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

Some Thoughts about Laptop WiFi Antennae

One fact which I had observed for some time, is that even many laptops today which have an LCD display, still use an Electroluminescent back-light, the latter of which needs to be activated with a kilovolt voltage, but the first of which only receives signals from the motherboard, that are too weak actually to emit a lot of light. And so, the circuitry has existed for some time, to take battery-level voltages, and to boost those into the kilovolt range, resulting in a very small number of microamperes of current. This is done with transistors, and with a special coil – which is also called “an inductive component”.

What the designers of laptops with EL backlights tend to do, is to feed the thin leads which carry this high voltage, through one of the hinges of the display / lid, in such a way that the leads make a gentle 90 degree bend on the side of the MB, and make a gentle 90 degree bend again on the side of the lid, while inside the hinge that connects the lid to the main body of the laptop, this set of leads only makes a 90 degree twist, or untwists, as the laptop lid is opened and closed. It is felt that this solution minimizes any wear and tear to the high voltage EL power leads, the insulation of which may be thin, even though that modern insulation effectively stops 1-2 kV.


But there is a report about those leads which some readers may already have encountered, according to which those form the WiFi antenna of the laptop. Well according to what I seem to have observed myself, Those leads fulfill both functions.

Because the low-current circuitry which puts the high voltage onto those leads feeds them through an inductor, a radio-frequency signal can also be fed onto the leads without interference from the LF high voltage, simply by looping them through another device, in series with the high voltage source. Even the fact that they have ‘a bit more insulation than an RF antenna should need’, will not interfere with their working as a WiFi antenna.

And I suppose that a question which users might ask could be, ‘Why would the Engineers go through the extra trouble, to allow the EL supply leads to double as the WiFi antenna, when low-voltage loops on the MB itself should also work?’

And as nearly as I can make out, the answer seems to be, that on most laptop designs, the display / lid is the only larger component, which goes from facing horizontally, to facing vertically, during normal use.


So, depending on what sort of troubleshooting one is doing, one might worry, that the same leads which feed the backlight, might also be starting to fail, in their function as the WiFi antenna. There is just one observation which needs to be added, to this statement of a hypothetical fear.

If those leads did become so frayed, that they no longer work as an RF antenna, then the user should also see some sort of negative effect, on how well the backlight maintains constant brightness. In fact, very shortly after the onset of trouble, the backlight should also fail completely.

This is not impossible. I have had separate monitors fail, due to the supply to the EL backlight failing. That monitor simply went blank, within a second of my powering it up eventually.

But there is something else which can resemble this situation, which is not as negative a prognosis for a laptop. After all, if those leads needed to be replaced, doing so would effectively amount to a mess.

In the modern world of Quantum Mechanics, we might not like to be reminded of this, but practical antenna geometry is still defined by waves and nodal lines. The advantages of having put an antenna into a laptop lid can disappear completely, when we just close the lid and have the laptop idling in standby.

The geometry with which such an antenna sends and receives radio waves, can effectively collapse, just as a function of the lid being made horizontal again, flush with the motherboard.


So there could be a number of reasons for which a WiFi connection can fail, and I have just searched for a software problem, in ways that seemed to take me four ways to hell and back, when in my case, simply moving the laptop to the other end of the table it rests on, facing in an opposite direction, may have solved the problem for me.

I know that as long as the WiFi works 90%, and as long as my display works 100%, I will not need to dig any deeper into the inner workings of this laptop for now.


(Edit 04/30/2016 : ) One result which does not occur easily in Electronics, is the perfect separation of signals. Thus, closing the laptop lid will not reduce the amplitude of the received WiFi-signal to zero, but will only attenuate it. Likewise, if the same wire is being used as WiFi-antenna as is being used as EL power supply, using it for the latter, also injects background noise into the weak WiFi signal received as the former.

I now suspect, that whenever a Windows laptop lid is closed, Windows settings make extra sure, to turn off the display as well, so that this issue is less of  a real problem.

Further, one of the many, many KDE power saving settings we can decide, is that Laptop Lid Closing Action is Turn the Screen Off.

But beyond that, KDE has more settings. Typically, I will tell my computers to Start displaying the Screen Saver / Locker after 10 minutes, and then to turn the Display Off after 30 minutes of inactivity total.

If the screen has been turned off as the Lid Close Action, this does not turn on the Screen Saver. Thus, with such settings, it can be that KDE next turns the Screen Saver, and thus the display, back On after 10 minutes, to display a Screen Saver which nobody ever sees. And then after another 20 minutes of that, these KDE settings should cause the display to turn off a second time.

In the meantime the WiFi antenna would receive no incoming signal for 20 minutes, starting from 10 minutes after I had closed the lid.

This might sound very strange to some Windows users, but simply follows mechanistically from such settings.

So I am now experimenting, with setting the laptop Lid Close Action to be Turn the Screen Off. But then I am setting the Display Power Saving Off Delay, to be equal to the number of minutes, within which the Screen Saver will Turn On.

Hence, my new settings should never allow for the display actually to be on, while the lid is closed. And then we will see, whether this laptop seems to disappear off my LAN again…


(Edit 04/30/2016 : ) The affected laptop has now been able to stay visible on my LAN, with its lid closed, for 12 hours overnight, while previously, it used to vanish off my LAN within a few minutes of my closing the lid, regardless of what my software settings were.

So I am declaring this experiment a success.

And for the same reason, that I am linking the current posting, as relevant to This Earlier Posting.


BTW, In order to test this visibility, I have been using a 3rd-party Android file manager app, which is also particularly efficient as a share / LAN browser. As it happens, my router has been enthusiastic enough, to continue to register the laptop ‘Klystron’ as connected, after its signal was lost, and after I could no longer get data to and from it.

But this 3rd-part LAN-browsing, Android app, will show me honestly, that the laptop has quit the LAN, within a few moments of the laptop doing so, which the laptop has not done for more than 12 hours now.

Further, this 3rd-party LAN-browsing app is also sophisticated enough, to display the computer I use as my server (‘Phoenix’) twice, once with its real IP address, and a second time with the IP address of its OpenVPN presence. That makes this app the only software I presently have, that can even detect my VPN, from elsewhere on my physical LAN.


(Edit 05/01/2016 : ) My laptop has now stayed connected to my WiFi for more than 24 hours, and without any glitches at all, with its lid in the closed position. So again, the simple fact that its display is off now, 100% of the time the lid is closed, seems to have helped.