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.

I have a VPS server with Media Temple, running CentOS with Plesk Parallels installed. It has a VPN module which I would ultimately like to configure to allow multiple clients to connect to the VPN server and be able to route all web and local traffic through the VPN server. This is the server config:

#
# Automatically generated by Plesk VPN module
#
lport 1194
ifconfig 10.yy.xx.1 255.255.255.252
daemon
secret /usr/local/psa/var/modules/vpn/vpn-key
writepid /usr/local/psa/var/modules/vpn/openvpn.pid
mtu-disc yes
comp-lzo
dev tap
float
keepalive 10 60
ping-timer-rem
resolv-retry infinite
push "dhcp-option DNS 10.yy.xx.1"

on the client side I have the following config:

#
# Automatically generated by Plesk VPN module
#
remote xcxcxcx.com
nobind
rport 1194
ifconfig 10.xx.yy.2 255.255.255.252
secret vpn-key
comp-lzo
dev tap
float
keepalive 10 60
ping-timer-rem
resolv-retry infinite
route-gateway 10.xx.yy.1
redirect-gateway

I should mention that although the comments say the files were auto generated, they've been modified manually since being created. At the moment I'm able to connect to the VPN server and even ping the gateway 10.xx.yy.1, but when I ping google.com for instance, it times out. It resolves the domain to an ip correctly, but there doesn't seem to be data flow. I'm at a complete loss. Any suggestions?

share|improve this question

3 Answers 3

Did you turn on IP forwarding on the VPN server?

echo 1 > /proc/sys/net/ipv4/ip_forward
share|improve this answer
    
yep, definitely turned on. –  Steve Apr 8 '11 at 4:35

The server.conf comments says this about the redirect gateway directive and could be helpful:

If enabled, this directive will configure all clients to redirect their default network gateway through the VPN, causing all IP traffic such as web browsing and and DNS lookups to go through the VPN (The OpenVPN server machine may need to NAT the TUN/TAP interface to the internet in order for this to work properly).

CAVEAT: May break client's network config if client's local DHCP server packets get routed through the tunnel. Solution: make sure client's local DHCP server is reachable via a more specific route than the default route of 0.0.0.0/0.0.0.0.

share|improve this answer
    
True, however, when I connect to the VPN and ping google.com from a local shell it responds with: Pinging google.com [72.14.204.103] with 32 bytes of data: and then times out. The IP address it shows proves that DNS lookup works, but data isn't flowing between the server and google.com –  Steve Apr 8 '11 at 5:55
    
The DNS lookup works because you are using the VPN server resolver. Your VPN client makes a query using 10.xx.yy.0 network to reach the DNS server and resolves correctly the name. –  lrosa Apr 8 '11 at 6:27
    
But you still have a 10.xx.yy.0 class IP address and without a NAT you go nowhere with that address. –  lrosa Apr 8 '11 at 6:28
    
Do I need to enable NAT on the server? –  Steve Apr 8 '11 at 7:26
    
Exactly! Otherwise your connection is limited to the local server. –  lrosa Apr 8 '11 at 7:27
up vote 0 down vote accepted

Alright, so here's what worked:

iptables -A INPUT -i tap+ -j ACCEPT
iptables -A FORWARD -i tap+ -j ACCEPT

RETURN     all  --  0.0.0.0/0            10.66.77.0/30
SNAT       all  --  10.66.77.0/30        0.0.0.0/0           to:72.10.36.151

The second portion works to replace MASQUERADING which is not available in a virtualized container environment. The iptables modules which can be found with lsmod simply aren't loaded by the host. The two rules used ensure that traffic flows between the VPN subnet and the internet. Thanks to Irosa for helping out with some fresh ideas.

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.