Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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.

share|improve this question

2 Answers 2

There are two other ports to forward, they are 443 and 943, as stated at FAQ from OpenVPN:

Which ports do I need to open in my firewall for Access Server?
Short answer: TCP 443, TCP 943, UDP 1194

And, if this doesn't work and all the IPs are public, you may try and remove the MASQUERADE, and let the connection to be made from P-t-P, passing through your gateway.

If none of these helps, you may need to give some more info, such as tcpdump excerpts, of even debug logs.

share|improve this answer
    
I will try that. But don't I have to masquerade in order to let the answers from OpenVPN come back through my gateway? –  wullxz Jan 12 '13 at 7:12
    
Since all your machines have valid IPs, the connection will be established with your gateway, get redirected to your VPN server and back through your gateway, but using the real IPs –  fboaventura Jan 12 '13 at 11:51
    
After we set the VPN server to support a proxy, I retried the iptables-gateway solution and it showed that we do need MASQUERADE and that it is ok to only forward port 1194. –  wullxz Jan 17 '13 at 6:56

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.

share|improve this answer
    
Sadly, we can't really use options that require additional configuration on the client (as long as it's not possible to deploy the configuration with an ovpn config) because there are several OSes among the clients. We tried hiding the network traffic with a proxy but it's also not possible to use a SSL proxy to hide SSL traffic. Our idea was to automatically test if our gateway is already blocked and then create another one (virtual environment) until we find a better solution. This will work some time because we observed, that it needs about 24h to 48h to get our VPN server blocked. –  wullxz Jan 16 '13 at 15:16
    
I'll accept your answer because we ran the SOCKS solution for some time until they blocked your DNS name and I don't want to waste the bounty. –  wullxz Jan 17 '13 at 6:53
    
Heh, thanks! :) I'm sorry you didn't find an answer, but I think in reality it just sounds like a mouse-cat game that you're playing. However, since it usually takes them about a day to find out of your new server, perhaps you can somehow implement your VPN through TOR? Perhaps they just account for total traffic between hosts and look at outliers, then by using many entrance nodes, you can minimise the exposure through the total amount of bandwidth? However, you kinda made me curious to know who is it that's blocking your VPN so proactively and whom you can't ask for some cooperation. :-) –  cnst Jan 17 '13 at 8:02

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.