[sc:internet-category ]I’ve been using OpenVPN Access Server for quite a while, I set it up on port 8080 as I already had my Exchange server using port 443 on my router. This wasn’t much of an issue as 8080 is pretty common and isn’t blocked very often.
However when I had to replace my DOCSIS cable modem recently I had to upgrade to the “wireless” router model and it used port 8080 as part of its administration interface.
Finding another common port that didn’t get blocked seemed like a challenge, so I decided to see if I could setup Apache as a reverse proxy in front of Exchange and OpenVPN.
Port Sharing
Turns out there is an even easier option. OpenVPN supports a mode where it sits in front of another web server, any OpenVPN connections are handled by OpenVPN and everything else is just passed through to the web server.
This article, while short get’s to the point pretty quickly.
As I used a UCC SSL cert for my VPN/Web server I didn’t expect there to be any certificate issues with connections.
As I’m using the Access Server (AS) VM I didn’t want to mess around with the start scripts and config files, fortunately AS provides an option to add extra configuration lines through the web interface. Simply go to “web admin->Advanced VPN->Additional OpenVPN Config Directives (Advanced)->Server Config Directives”, add the following line:
“port-share xxx.xxx.xxx.xxx 443”
This enables the port sharing mode and redirects the traffic to port 443 on the supplied IP address. After restarting the services, connecting to the AS on port 443 brought up my web server instead of the AS, as expected. One thing this does limit is that you can no longer access the AS web interface for downloading the client or profiles. Not a big deal, but something to be aware of.
Another thing to be aware of, that isn’t document very well is that port sharing only works across UDP. More to the point, you have to set AS to use TCP only, you cannot use the “both” setting or an error is generated during the service start-up and AS fails to run.
The next step was to connect to the VPN and test to make sure it still worked. Using my laptop to connect from within my network failed, the connection would start to set up and then give a disconnect error.
Looking through the logs came up without much help, but I did notice the clock on the VPN servers was significantly out of sync (days of drift) so I reset them and tried again. However still no connection.
Upgrading OpenVPN AS
My next thought was perhaps a bug in the version of OpenVPN I was using, I was a few versions behind with 1.8.3. 2.0.3 had been released a while ago so I decided to upgrade.
I had written a little upgrade script on the VPN servers which did the work for me but when I tried upgrading to 2.0.3 an error came back as the script could not find the 2.0.3 packages on the OpenVPN site.
Looking around turned up the problem pretty quickly, the AS VM I was using was based on Ubuntu 8, and in the version 2 release of AS, they dropped support for 8 and moved to 13.
To top it off, there is no upgrade path for the old AS to Ubuntu 13 so it means re-creating the AS VM’s from scratch. This is not a huge deal and only took a few minutes, but I did run across one item that was an issue.
In the old AS, they provided a GUI interface for setting up the static IP address of the server, in Ubuntu 13 they didn’t both to bring this across and let you manually configure the interface by editing ‘/etc/networks/interfaces’. The instructions are included on the AS download page but are a little miss leading.
Step three is:
Add the following lines using the template below: address 'ipAddr' netmask 'subnet' gateway 'gw' dns-nameservers 'dns1' 'dns2'
But that’s not quite true as it would lead you to believe that it is one line with all the options on it. Instead you have to split each option on to its own line like so:
address 'ipAddr' netmask 'subnet' gateway 'gw' dns-nameservers 'dns1' 'dns2'
Likewise, bring the interface down and then back up, does not work as documented. You need to reboot the server to get it to work correctly.
I also changed the hostname, which they don’t document but is just a simple edit of /etc/hostname.
I then ported across my upgrade script which now looks like:
wget http://swupdate.openvpn.org/as/openvpn-as-$1-Ubuntu13.amd64.deb dpkg -i openvpn-as-$1-Ubuntu13.amd64.deb rm openvpn-as-$1-Ubuntu13.amd64.deb
Ran the apt-get to upgrade the OS and then upgraded to OpenVPN 2.0.3.
More Troubleshooting
After a reboot, same issue. Connecting to the VPN failed with a disconnect each time.
Removing the port sharing option allowed the VPN to connect but of course didn’t pass through to the web server.
Trudging through the log files I found that OpenVPN was failing to detect the VPN connect and passing it through to my web server, which obvious would not recognize the connect.
My first though was that, since I have my OpenVPN setup in failover mode, that perhaps this was interfering with the port sharing.
I spun up another VM with AS and shutdown my current VPN servers and tried it as a single server instead. No difference.
Searching the internet I found lots of people having issues with port sharing, but they had the opposite issue I did. They’re VPN connections worked but pass through didn’t.
I have yet to find a solution to the problem and so I have instead configured OpenVPN to use port 943, the alternate HTTPS port which seems to be working fine.
Performance Tuning
Well almost fine.
The first time I connected remotely performance was terrible. Dropped packets, connection drops, 1+ second ping times.
At first I though it might just be my connection at home or my current location, but when I took a look at the OpenVPN server at home, it was running very slowly as well.
When I upgraded to the new VM image for AS, I simply pulled the virtual disk and attached it to the existing VM’s I had on my server. Turns out the memory requirement went up a little bit between the old and new AS. I added some additional RAM to the VM’s, reboot and everything seemed much better. The next day at my remove site performance was back to normal as well.
Summary
So what did I learn from this?
- Well, port sharing is complex, finicky and apparently doesn’t work.
- Upgrades from 1.x to 2.x aren’t simple with OpenVPN.
- When building new VM’s, start from scratch 😉
Overall OpenVPN 2 doesn’t really bring much new to the table but it’s good to get the upgrade done and over with.
My last thought about the port sharing is that perhaps it’s just broken in AS. I may, if I get some free time, try building a Ubuntu VM and installing OpenVPN from the source code to see if I can figure out what’s wrong with it.
However as port 943 seems to be working fine and it does give me the added benefit of having access to the web interface for OpenVPN, I don’t think I’ll change it at this point.
