Routine OpenVPN Test Successful Today

On my home server I also host a VPN, which is based on the OpenVPN protocol, and which is secured by password-challenges and encryption keys. From time to time I carry out a test of this VPN – i.e. from outside my LAN – to make sure that software-updates and other changes have not caused it to stop working.

Today I went to a public WiFi hot-spot, and carried out such a test.

This test was a bit different from earlier tests, in that it was the first time I used my new Pixel C tablet as the client.

The test was a full success. At first, after I had logged in to my VPN, I tried pinging another computer on my LAN. Then, I created a remote desktop session on one of my computers, in which the desktop session was being handed through to my tablet, by way of the VPN.

What this means is that my new Android 7.1.2 tablet is fully compatible and set up to use this feature.


(Edit 04/18/2017 : )

I have noticed that performing this test also knocked my Google Calendar app out from syncing. This caused a famous situation, in which the app was still displaying my schedule, but the tablet was no longer giving any notifications, for the reminders programmed in my calendar. This caused me no immediate distress, because I possess sundry other devices, which give alarms to signal the same reminders.

But the way in which I got the tablet to rejoin this chorus, was by first telling the Android Application Manager to erase the Cache of this one app, and then to go into the Accounts settings panel, to go into my Google Accounts, and from there, to toggle syncing of the Calendar Off and then On again.

After that, the app has been sounding all the reminders as before.


How DynDNS Works

You could face the following problem. You could be intending to set up your own Web-server, for it to be visible to the public, on your home computer. You could have an ISP, which assigns and reassigns you IP addresses which they own, and which therefore, you do not own as static IP addresses.

You could have taken the step of installing a Web-server on your machine, as well as to do “Port Forwarding” on your router, meaning that the router listens on Port 80 on the WAN, and forwards all incoming connection attempts to that port, to the host machine on your LAN.

You would now have the problem that your Web-site needs a URL, with a domain name, which anybody on the Internet can use, to access your Web-server. After all, your IP address can change, and it would not be practical to update people directly, with your new IP addresses.

There is a freemium service on the Web, which would be able to help you with that problem. When we give our Web-browsers a URL with a domain-name, the browser accesses a public DNS server, to look up the IP address of the Web-site, associated with that domain name. “DynDNS” offers a specialty service, by which its members have ‘a Dynamic DNS service’. Its members install an update client on their machines, and reserve a domain-name with DynDNS, which is to be associated with their potentially changing IP address, continually.

Whenever the ISP changes our IP address, the update client on our computers detects this, and logs in to the DynDNS account we have. Then, the update client notifies DynDNS of the new IP address, and DynDNS has the connections with the public network of DNS servers, to propagate the new IP address. It is the responsibility of DynDNS, that requests for domain-names which its members hold, from Web-browsers, be answered with your updated IP address.

The Web-browser is never notified in any way that your IP address or domain name are different from ones with static IP addresses, it simply receives the IP address from its subscribed DNS server, that is your WAN address, and connects to it.

Further, if you have registered a host-name, as they call it, with DynDNS, there is no specific reason why you would need to listen on Port 80 always. Your purpose could be to make other services publicly-accessible, which listen on other port numbers, which you have instructed your router to forward to some machine on your LAN.

This is the arrangement by which I host my own Web-site, and additional services, from my home computer.


dirk@Phoenix:~$ host has address has IPv6 address 2001:0:53aa:64c:d1:32e7:b9cc:d8a8 mail is handled by 10




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

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…