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.


OpenVPN, NoMachine NX Test Successful Today

The computer I name ‘Phoenix’ is not only my Web-server, but also a VPN server, which gives secure access to my LAN here at home, using the OpenVPN protocol. From time to time I test whether this system still works, because of software-updates and other changes which have taken place.

Today I conducted such a test, by taking my Android tablet – that has the OpenVPN Client installed – to a WiFi hot-spot, and by connecting to my Home VPN from there. This succeeded.

Then, I went further with my test, by creating a remote desktop session over the VPN tunnel, with my hosting computer named ‘Klystron’, using NoMachine NX. This test was also a success. I was able to log in to the desktop of Klystron remotely.



Bell Hub 2000 Idiosyncrasy

It has come to my attention that there exists an idiosyncrasy in the way the Modem/Router of my ISP works, the new modem I was just given, which can lead other Bell customers to confusion.

In its port-forwarding rules, we can select whether we would like to forward a TCP port, a UDP port, or Both. People may habitually choose Both, maybe even because we do not remember which protocol we are using, only which port number it listens on.

If the LAN-computer is only listening on the corresponding UDP port, and we have told this router to forward Both, then an external port scan will tell us, that Both Ports Are Closed. This is because the corresponding TCP port on the LAN machine Is Closed, and because UDP ports generally do not have to report back, when they receive packets. UDP ports are stateless.

Thus, If some people have naively set up an OpenVPN server to listen on the UDP port, but have told the router to forward Both port-types, and if they then try to connect, the failure of the server to respond could have several reasons. But then, if those users ask an external port-scanner to give them the status of the WAN port, the scanner will tell them that the port is closed, and the users may jump to the conclusion, that they are being blocked on the side of the ISP, because obviously, the dedicated port-scanning site would not be blocking them, for the purpose of testing whether their WAN port is in fact listening.

Continue reading Bell Hub 2000 Idiosyncrasy