up vote 0 down vote favorite
share [g+] share [fb]

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?

link|improve this question
feedback

3 Answers

up vote 0 down vote

Did you turn on IP forwarding on the VPN server?

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

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.

link|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
show 4 more comments
feedback
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.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

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