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

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 iptable.sh 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 http://www.google.com, I see the "It works" default page of the Apache2 server which is running. I don't really understand why... Here's my configuration:

/etc/openvpn/server.conf

mode server
tls-server

port 10735
proto udp

dev tun0

# Certificates, blablah...

# Virtual addr conf
server 172.16.0.0 255.255.255.0

push "route 192.168.0.0 255.255.255.0"
push "dhcp-option DNS 8.8.8.8"

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

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

iptables -A FORWARD -s 172.16.0.0/24 -o eth0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.16.0.0/24 -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 172.16.0.0/24 -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 172.16.0.0/24 -j SNAT --to-source 89.2xx.xxx.xxx  <- 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 serverfault.com
    PING serverfault.com (198.252.206.16) 56(84) bytes of data.
    64 bytes from stackoverflow.com (198.252.206.16): 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. –  Peter Horvath Dec 2 '13 at 20:00

3 Answers 3

up vote 1 down vote accepted
+50

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 89.2xx.xxx.xxx (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 89.2xx.xxx.xxx - 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 - 172.16.0.0

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

 
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.