OpenVPN

All I need was UDP port 1194. All they had to do was to configure the firewall.

And it got complicated.

They claimed they couldn’t set it up in the remote office because OpenVPN would require administrative privileges in order to establish a connection. So I said, “Well, start it up on a gateway server and route the clients through.”

That was Friday, and earlier today I was told that they managed to setup as planned but would require every node behind the OpenVPN server to include new IP routing entries. That’s because the clients behind the gateway would report their internal non-routeable IP addresses instead of the IP class recognized by the OpenVPN server.

The situation, they explained for example, 172.16.0.0 under 255.255.0.0 making a request to a node behind an OpenVPN server that is expecting a non-routeable IP class of 192.168.105.0 under 255.255.255.0, would result in lost packets unless the nodes themselves know how to reply back to the 172.16.0.0 class.

There’s no way I’m going to add 172.16.0.0 class to every single node behind the VPN server! So I told them that I can do a proxy server, the port-forwarding kind. They offered to do NAT instead (smart!), and by afternoon, the developers finally managed to connect to the network. Problem solved.

In another remote office, the administrators thought that VPN would mean port 1723. That would be the case if I was running on Microsoft Windows VPN. It took like 5 hours of my life and a Powerpoint slide to convinced them to open up UDP port 1194. Thankfully, this time around, there weren’t any complicated security matrix or IP routing involved.

And that wasn’t the end of it.

While testing the connectivity, I had lowered down the firewall on the OpenVPN server (yes, it was stupid, I know!). By the time I got to verify the packet rules needed, the server had been randomly victimized by DoS attack.

I could have gone bonkers, but when I realized that it’s Monday I know some things are just deemed to screw-up.