VPN Server Test Completed Today

Just this evening, I went to my neighborhood Tim Hortons, to order some food, but also to use their public WiFi hot-spot, in order to log in a session with the VPN server I have on my LAN, that uses the ‘OpenVPN’ protocol. This is a type of test which I perform periodically, just to make sure that the server does work, after certain upgrades. The test was a success.

But I would like to point out several things which this action does not imply.

In the world of today, many people pay money to rent a VPN server, the only purpose of which is to fool the geo-blocking of certain services offered in the USA. In this context, they may expect that to install ‘OpenVPN’ on their clients, will give them free access to a VPN.

This would be False.

The way I have OpenVPN set up on my LAN, I can use the compatible Android client, named “OpenVPN For Android”, to make my computers behave as though my tablet was physically on my LAN. From there, I can ping computers on my LAN. This could be useful to me if I need to access certain resources that specifically exist on my LAN here at home.

In general, I do not use this service to redirect any Internet traffic through my VPN, so that Internet traffic continues to flow directly from the tablet which is my client, through the WiFi that I have used separately, to gain access to my OpenVPN server.

Some people have suggested that I may be taking quite a chance with my data, by connecting to my VPN from within a WiFi hot-spot. But contrarily to what the name of this protocol may suggest to some minds, this protocol has robust encryption techniques in place, in addition to password challenges, which will not only prevent unauthorized access, but also prevent any data from being gleaned from the connection, in the event that the entire session might be monitored.

My main fear in this scenario tends to be, that certain hot-spot operators may not differentiate, between a person who connects to his VPN at home, and one who connects to a VPN across the border, simply because either type of session typically uses the same port numbers, only on different servers. If they did not differentiate, my access to any VPN might be blocked regardless. It was not blocked this evening.

There is an observation about Tim Horton WiFi however, which I may mention. I pinged another computer tonight, which was physically on my LAN. This represents a low-bandwidth scenario. The ping times were slower than before, averaging maybe 200ms. In the past I sometimes obtained ping times of 30-50ms. Yet, if I was to do the same thing from a non-public WiFi hot-spot, my ping times should also be back to normal…

Dirk

 

I do not own my own router.

One thing which exists in a big way in Canada, is that ISP subscribers own their own router. But as it happens, my router is owned by Bell and rented to me. The official reason for this, is the fact that my router also provides me with Bell Fibe TV, which contrarily to the naming, is in fact provided over IP via DSL twisted-pair wires.

This paid-for TV content is DRM, so that it is hard to imagine that any other computer enthusiasts have managed to set up their own router, and to receive Fibe TV anyway.

But this also means that I do not have the access to flash my own router. Bell can flash the router when they see a need, but I cannot. And this also means that I cannot obtain full control over this router.

Readers might think that this is an odd situation, for a person who sets up a Web-server, and an OpenVPN-server, at his home IP address. But by using IP-tables in my Linux configuration, I have been able to do precisely that. In particular, the OpenVPN-server requires an ‘IP Masquerade’ to work. But as of my last test, it does work.

But because I am a person who ‘sometimes thinks suspiciously’, I have also had ideas, about what other consequences might arise, from the router being under the control of somebody else. One thing which may happen, is that this router, which displays no options or information regarding IPv6, may get confused and start dropping clients, over repeated requests for IPv6 addresses.

The Web-interface of this router is a dumbed-down interface, which I can access, but which for my benefit, does not give me deep control over the settings. One thing which remains true however, is that in Canada, there is next to no real use of IPv6 from the side of ISPs.

Now, I have set up an IPv6 gateway, which allows my site to be fetched by way of IPv6 if this is desired. But I have also set up my ‘ip6tables‘ in such a way that any request my Server makes for an IPv6 address, gets routed to this gateway, and not to my physical Ethernet connection. It is only logical. So ‘ping6‘ works gloriously on the Server, but not on my laptop. When I do a ‘ping6‘ on my server-box, I also get to see a graphical display in my ‘gkrellm‘ monitor widget, of activity going out over my ‘teredo‘ virtual NIC, not over my real NIC.

And so I have a somewhat lopsided configuration at home, but one which does what I want it to do.

Dirk

 

I can make simple mistakes, configuring Linux services.

One of the things which I do, is to operate an ‘OpenVPN’ server, the sole intention of which it is, to give myself access to resources on my LAN, while I am someplace else, let us say with my tablet as a client. This OpenVPN server uses encryption to secure access to my LAN, including a private and a public RSA key-set. And one of the abilities which I would like to have, is to revoke a client public key, in case one of my tablets was ever to get stolen or otherwise compromised.

The way this works with OpenVPN, is that the file which stores the CRL needs to be identified to the server at start-up, but after that, any public keys added to that file are effective immediately, because OpenVPN will check this file, every time a client logs in, assuming again, that this file was recognized once, when the server was started.

And so I added the following specification to my VPN config file some time ago, to prepare my CRL for eventual use:


crl-verfiy /usr/share/easy-rsa/(...)

I was disappointed to find, that once, as a part of my log-rotations, my OpenVPN server was restarted on April 1, it simply refused to restart. The reason had something to do with this specification. And so I actually searched high and low to find an external reason.

One reason some users give for this not working, is the fact that on their systems, OpenVPN runs as a user different from ‘root‘, and that on those systems, the file ‘crl.pem‘ needs to be made readable by the username which OpenVPN runs under. But the way my distribution is set up, OpenVPN simply runs as root. And so this frequent recital of a reason on the Web, for which this specification might not work, actually slowed down how long it took me, to find the reason, which applies to my system.

It took me more than an hour, to see that I had mistyped something, in that I had entered an ‘f’ and and ‘i’ in the wrong order. So once I corrected this typo, the server restarted fine.

But the world of Linux is still such a place, in which such a typo on the part of the user can stubbornly prevent something from working, until the source of the error is uncovered. This does not change core ideas I have about how the world works. It simply reminds me, that I should not make careless mistakes such as this one.

And it reminds me, that in theory things might seem easier to do, than they sometimes are in practice.

Dirk

 

Narrowing an old Problem with Teredo

I happen to have a package installed on my Linux server named ‘Phoenix’, which gives me access to IPv6 via a remote ‘Teredo’ server acting as a tunnel, and which gives me this connectivity, even though my ISP does not yet support IPv6. The Teredo server I use is not the Microsoft Teredo server, which AFAIK has been shut down by now, on the assumption that Teredo is outdated.

This Teredo connectivity presents itself to me on the user / application level, as a virtual network interface, which applications can connect to as easily as to the physical interface, but which has been implemented behind the scenes, as a translation process for data, that finally communicates over the real, physical interface. Both Linux and some Windows computers can generally do this, via the ‘TAP Device’ or ‘TUN Device’ API, which in turn needs to be supported by either kernel.

In addition to the ‘teredo’ virtual network interface, I also have another one, which is simply named ‘tun0′ on this server, and which enables my ‘OpenVPN’ server. I will not go into the details in this posting, of how to set up OpenVPN, which is a somewhat complex process documented in several other places on the Web.

But my setup effectively causes two TAP and/or TUN devices to appear as part of my network configuration by default. These two devices should not interfere which each other in principle. But by default, my ‘tun0′ interface is created during the boot process, before my ‘teredo’ interface is created.

I seem to have a glitch in my kernel, which will require that they always be destroyed in the reverse order initially created. Hence, if my ‘teredo’ interface is Up, but I next shut down my VPN, and when I next restart my VPN, the ‘teredo’ interface will fail, and will seem to lose its IP Configuration, as far as my desktop tells me, and as far as an ‘ifconfig -a‘ will confirm. Thus, I will next need to restart my Teredo service as well, in order to reestablish that.

This is a minor problem, but may have led to earlier issues, which I had thought at that time must have come from the Teredo tunneling server, which I am using. More precisely, I now think that some Teredo-related problems I was having, were actually due to log rotations which my server does.

Some of my earlier Teredo, IPv6 issues were described in This Earlier Posting. As it happens, February 13 was a Saturday, and so it is not clear how a log rotation might have caused this exact malfunction. But the problem which I now anticipate, and which would be due to my client would be as follows:

Once per month, my VPN server is given a restart scripted by me, in order to be able to close its log file and to open a new log file associated with the process. This restart can happen more or less alphabetically, without respecting any preferences that the kernel might have, for the order in which one virtual interface might be affected by the other – while neither should affect the other in principle.

It is interesting to note that my VPN configuration is created by me, while the Teredo client runs out-of-the-box, and is intended to have no log rotation, by the package maintainers.

And the result can be, that my ‘teredo’ interface goes down, leaving me with no IPv6 connectivity for the moment. I find that in practice, the ‘tun0′ interface is not affected by this fragility. And so when that happens, I need to play with my Teredo service to get it running again. And this can all happen without any knowledge, from the people who run the remote Teredo tunnel.

Dirk