Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to configure a VPN on a new virtual server, powered with OpenVZ. I took the configuration of my current VPN, which is hosted on a Xen VPS and pasted it on my new server. After many tries, I look on different topics and see that OpenVZ doesn't support the MASQUERADE option of iptables. So I try to create a file, by following this blog post.

When I'm connected to the VPN, every page is fetched from my webserver (on the same machine as the VPN)... For example, if I try to access to, I see the "It works" default page of the Apache2 server which is running. I don't really understand why... Here's my configuration:


mode server

port 10735
proto udp

dev tun0

# Certificates, blablah...

# Virtual addr conf

push "route"
push "dhcp-option DNS"

# Log, persitent connections, max clients, blabla..

Old iptable conf (on my previous server, with MASQUERADE working)

iptables -A FORWARD -s -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE

New iptables conf (stored in .sh file)

/sbin/iptables -F
/sbin/iptables -P OUTPUT ACCEPT

/sbin/iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -s -j ACCEPT

#/sbin/iptables -A FORWARD -j REJECT

# Perform NATing on outgoing packets to change the IP address the packets come from
/sbin/iptables -t nat -A POSTROUTING -s -j SNAT --to-source  <- my public addr

/sbin/iptables -A INPUT -p udp --dport 10735 -j ACCEPT
/sbin/iptables -A INPUT -p icmp -j ACCEPT
/sbin/iptables -A INPUT -i lo -j ACCEPT
/sbin/iptables -A INPUT -i tun0 -j ACCEPT
/sbin/iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Thanks in advance :)

Additional information
  • No problem with the VPS connection, I can ping several domains/IP...

    ~# ping
    PING ( 56(84) bytes of data.
    64 bytes from ( icmp_req=1 ttl=50 time=58.5 ms
  • http://<public VPS IP> returns to the "It works" page I getted with the VPN.

  • cat /proc/sys/net/ipv4/ip_forward returns 1 (IP forward activated)
share|improve this question
I suggest to play a little bit on the ip level (what is pingable? How works traceroute?), mystic http-level redirections aren't really helpful to remote debugging. But if you have some type of http proxy, my first tip were some ip-change-based ServerName problem, not in your iptables but in your proxy config. – peterh Dec 2 '13 at 20:00
up vote 1 down vote accepted

Difference between SNAT and MASQUERADE: first working faster but second is working with dynamic WAN IP (using route table lookups).
Many of Cloud VPS services like Amazon configures DMZ for you: so your external IP adress is not your IP on external interface of your server. All connections to any port forwarding from your (which is really used by network hardware) to your WAN iface.
So, TCP request on http://'public VPS IP' will be processed by the provider and unconditionally redirected to your eth0. That's why your see 'it works'.
But if you try to set all outgoing packet's SOURCE IP field to - provider's network evaluating it as spoofed packet and drop it.
So you should use IP address assigned to your eth0 iface for SNAT (i guess it differs from external).

Check if your eth0 subnet is not intersecting your VPN subnet -

share|improve this answer

I have my OpenVPN server setup through a VPS and I had to use the following command to make the NATing work since MASQUERADE wouldn't. Once I put it in and ensured that I allowed forwarding rules and also turned on ip_forward on /etc/sysctl.conf, I was good to go.

/sbin/iptables -t nat -A POSTROUTING -j SNAT --to-source external_ip_of_the_server
share|improve this answer
Thanks for the answer. I already had activate the IP forward and try the exact same rule as you (with my external VPS IP of course), and it does the same thing... :( – Maxime Lorant Dec 3 '13 at 16:19

Well, according to symptoms you're describing your firewall seems to have DNAT rule redirecting access from outside to internal-IP-address:80. This rule doesn't consider incoming interface, therefore all your outgoing requests are also being DNATed. You have to use such kind of DNAT redirect only external interface exactly.

share|improve this answer

Your Answer


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.