Álvaro J. Iradier

Today I found an interesting problem. My workmate, working away from the office, needed to connect to our office network. For this, we usually use (OpenVPN) running on a linux box.

The problem is my mate was using a proxy as the only possible gateway to the internet. OpenVPN supports proxy connections, using CONNECT method (for HTTPS secure connection), providing you use a TCP connection instead of the default UDP. However, the proxy was a bit strict, and it only allowed HTTPS connections to port 443. Trying to connect to the port our VPN server was listening on (port 1194) or any other port than 443 resulted in a 403 Forbidden error from the proxy.

The solution looks easy: make openVPN listen on port 443. But it's not that easy. The same computer is running an Apache web server, listening on port 443, and we don't want to change that. After all, it's a standard for HTTPS.

The answer was NAT: Network Address Translation. We would mangle incoming connections from the proxy to port 443, so they new destination port is 1194. The tool is iptables:


PROXYIP="80.35.189.250"
iptables -t nat -A PREROUTING -p tcp -s $PROXYIP --destination-port 443 -j DNAT --to-destination 192.168.1.50:1194


Whis this small script, we say iptables that new initiating incoming connections from $PROXYIP, TCP, going to port 443, must be translated. The destination is changed to 192.168.1.50:1194 (this is the server running OpenVPN, in this case the same running iptables, so localhsot might have worked as well), and succesive packtes in the connections are tracked and correctly translated.

The only drawback is connections from that proxy won't be able to get to the HTTPS web site, as all incoming connections will be sent to the VPN server!

Another possible solution might had been creating an HTTP tunnel using HTTPTunnel, but this required a client side installation, and some tricks in our web server. The current solution is good enough for us.