Iptables – OpenVPN AS accept connections forwarded by NAT

iptablesnat;openvpnrouting

We're running OpenVPN AS servers which are accessable and working over a public IP.
But some of our clients aren't allowed to access our VPN server directly (because of some nasty firewall admin – don't ask…). To bypass that problem, we've come up with a setup that will create a gateway in a virtual environment which will do a simple NAT to forward all incomming connections to our VPN server.

NAT is working properly (tcpdump on the server shows the same packets that were leaving our gateway). Our current iptables roules are (INPUT, FORWARD and OUTPUT are set to ACCEPT by default):

iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT --to-destination $vpn_srv
iptables -t nat -A POSTROUTING -j MASQUERADE

I know that there might be some further configuration need but as long as the VPN server isn't responding to the packets he surely receives, there's no need for us to enhance the rules.

Every time a packet arrives at the VPN server, the server produces following log output:

2012-12-31 13:03:29+0000 [-] OVPN 1 OUT: 'Mon Dec 31 13:03:29 2012 TLS Error: incoming packet authentication failed from 123.123.123.123:35077'
2012-12-31 13:03:31+0000 [-] OVPN 1 OUT: 'Mon Dec 31 13:03:31 2012 Authenticate/Decrypt packet error: packet HMAC authentication failed'

So I suppose that we need to tell the VPN server to accept and reply to forwarded packets from this host. How do we do that?

Note: All servers (VPN server and NAT Gateway) are public.

Edit:
No Ideas? I know that it's possible to run an OpenVPN server behind a firewall (simple NAT as in any home network). How is my setup different from that one?

Edit (10.01.2013):
We would try any solution that allows us to forward the vpn traffic from a "gateway" to our vpn server. Preferably using an encryption because it seems that the firewall scans for specific vpn pakets which will be dumped.

Best Answer

If you have a client with a network-wide firewall that blocks OpenVPN traffic through DPI and/or some kind of pattern analysis, then I'm not sure you can do much about it, short of not using OpenVPN. I'm not sure I follow how using an extra gateway and NAT (I presume on your non-client network?) is supposed to help one bit.

What you can do instead is try using OpenSSH SOCKS or tun(4) functionality. (Provided that by some strange reasons only OpenVPN is blocked, but not ssh.)

The SOCKS functionality is supported by all major ssh implementations (it's often called "Dynamic Port Forwarding"), and it'll let your client connect and authenticate through SSH with -D1080 option, and then specify localhost:1080 as the SOCKS5 proxy within the web browser. Very simple to setup (no server-side changes are necessary if the user already has ssh access) and generally works great (I use it all the time from public networks).

Alternatively, if you're using a UNIX system, then you can configure tun(4) through OpenSSH, too. This is a relatively more recent feature, and it requires extra configuration compared to SOCKS proxying that's practically already enabled by default, but it's also a good option, depending on what you're looking for.

Related Topic