3

After reading many questions, the HOWTO, the FAQ and even parts of a guide to Linux networking, I cannot get my an Internet connection to the Internet.

I'm trying to set up a OpenVPN server on a VPS, which will be used for:

  • secure access to the Internet
  • bypassing port restrictions (directadmin/2222 for example)
  • an IPv6 connection (my client does only have IPv4 connectivity, while the VPS has both IPv4 and native IPv6 connectivity) (if possible)

I can connect to my server and access the machine (HTTP), but Internet connectivity fails completely. I'm using ping 8.8.8.8 for testing whether my connection works or not.

Using tcpdump and iptables -t nat -A POSTROUTING -j LOG, I can confirm that the packets reach my server. If I ping to 8.8.8.8 on the VPS, I get an echo-reply from 8.8.8.8 as expected. When pinging from the client, I do not get an echo-reply.

The VPS has only one NIC: etho. It runs on Xen. I would like to avoid network bridging (br0).

Summary: I want to have a secure connection between my laptop and the Internet using OpenVPN. If that works, I want to have IPv6 connectivity as well.

Network setup and software:

 Home laptop    (eth0: 192.168.2.10) (tap0: 10.8.0.2)
  |      |       (running Kubuntu 10.10; OpenVPN 2.1.0-3ubuntu1)
  | wifi |
router/gateway  (gateway 192.168.2.1)
      |
  INTERNET
      |
     VPS        (eth0:1.2.3.4)       (gateway, tap0: 10.8.0.1)
                  (running Debian 6; OpenVPN 2.1.3-2)

wifi and my home router should not cause problems since all traffic goes encrypted over UDP port 1194.

I've turned IP forwarding on:

# echo 1 > /proc/sys/net/ipv4/ip_forward

iptables has been configured to allow forwarding traffic as well:

iptables -F FORWARD
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j DROP

I've tried each of these rules separately without luck (flushing the chains before executing):

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to 1.2.3.4
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

route -n before (server):

1.2.3.4         0.0.0.0         255.255.255.0   U     0      0        0 eth0
0.0.0.0         1.2.3.4         0.0.0.0         UG    0      0        0 eth0

route -n after (server):

1.2.3.4         0.0.0.0         255.255.255.0   U     0      0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tap0
0.0.0.0         1.2.3.4         0.0.0.0         UG    0      0        0 eth0

route -n before (client):

192.168.2.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0

route -n after (client):

1.2.3.4         192.168.2.1     255.255.255.255 UGH   0      0        0 wlan0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tap0
192.168.2.0     0.0.0.0         255.255.255.0   U     2      0        0 wlan0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 wlan0
0.0.0.0         10.8.0.1        128.0.0.0       UG    0      0        0 tap0
128.0.0.0       10.8.0.1        128.0.0.0       UG    0      0        0 tap0
0.0.0.0         192.168.2.1     0.0.0.0         UG    0      0        0 wlan0

SERVER config

proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh1024.pem
server 10.8.0.0 255.255.255.0
push "redirect-gateway def1"
ifconfig-pool-persist ipp.txt
keepalive 10 120
tls-auth ta.key 0
comp-lzo
user nobody
group nogroup
persist-key
persist-tun
log-append openvpn-log
verb 3
mute 10

CLIENT config

dev tap
proto udp
remote 1.2.3.4 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert client.crt
key client.key
ns-cert-type server
tls-auth ta.key 1
comp-lzo
user nobody
group nogroup
verb 3
mute 20

traceroute 8.8.8.8 works as expected (similar output without OpenVPN activated):

 1  10.8.0.1 (10.8.0.1)  24.276 ms  26.891 ms  29.454 ms
 2  gw03.sbp.directvps.nl (178.21.112.1)  31.161 ms  31.890 ms  34.458 ms
 3  ge0-v0652.cr0.nik-ams.nl.as8312.net (195.210.57.105)  35.353 ms  36.874 ms  38.403 ms
 4  ge0-v3900.cr0.nik-ams.nl.as8312.net (195.210.57.53)  41.311 ms  41.561 ms  43.006 ms
 5  * * *
 6  209.85.248.88 (209.85.248.88)  147.061 ms  36.931 ms  28.063 ms
 7  216.239.49.36 (216.239.49.36)  31.109 ms  33.292 ms 216.239.49.28 (216.239.49.28)  64.723 ms
 8  209.85.255.130 (209.85.255.130)  49.350 ms 209.85.255.126 (209.85.255.126)  49.619 ms 209.85.255.122 (209.85.255.122)  52.416 ms
 9  google-public-dns-a.google.com (8.8.8.8)  41.266 ms  44.054 ms  44.730 ms

If you have any suggestions, please comment or answer.

Thanks in advance.

Lekensteyn
  • 6,111
  • 6
  • 37
  • 55
  • 2
    What does `ip route show` report (on both client and server) after you have established the VPN connection? – Steven Monday Feb 15 '11 at 00:12
  • @Lekensteyn, you realize that OpenVPN does not support IPv6 in routed (tun) mode right? If you want to use IPv6, you have to bridge (tap). – Zoredache Feb 15 '11 at 00:58
  • Also, traceroute is almost always a more useful then ping when testing routing, or VPNs. – Zoredache Feb 15 '11 at 01:01
  • @Steven Monai: added @Zoredache: I know, that's why I'm using tap. I will follow the instructions on http://silmor.de/64 for IPv6 if I got the IPv4 part working. – Lekensteyn Feb 15 '11 at 08:02
  • I've just set up a home network, and I cannot get it to work either. (laptop - home router - pc). – Lekensteyn Feb 15 '11 at 15:32
  • @Lekensteyn: Looking at the post-VPN-established routing tables, your routing appears to be okay. Agree with Zoredache: Try traceroute/tracert instead of ping. Another idea: You may want to check the packet counts with `iptables -L -v -n` on the server to see if your packets are being inadvertently filtered. – Steven Monday Feb 15 '11 at 15:51
  • @Steven Monai: Thanks for the hint on counts on the packet filter. With traceroute, I just see one hop: the machine name. Replacing the MASQUERADE rule with `-t nat -A POSTROUTING -o eth0 -j MASQUERADE` work in my home setup, but not in the server one. I'll apply the servers IPTables to the home pc to make the environments match more closely. – Lekensteyn Feb 15 '11 at 15:55

2 Answers2

3

It turned out to be an issue at the providers side, they had outdated network settings for Xen. For the IPv6 journey, see How can I setup OpenVPN with IPv4 and IPv6 using a tap device?.

Community
  • 1
Lekensteyn
  • 6,111
  • 6
  • 37
  • 55
0

I'm not sure I'm onto something here, but it looks to me that you allow forwarding when source is 10.8.0.0/24, so how do you expect the reply from destination 8.8.8.8 to traverse to 10.8.0.0/24 then?

3molo
  • 4,340
  • 5
  • 30
  • 46
  • That should be handled by `-m state --state ESTABLISHED,RELATED`. I do not see anything in my logs if I add `iptables -t nat -I POSTROUTING 3 -j LOG`. – Lekensteyn Feb 15 '11 at 11:36
  • ah, true. What do you see if you tcpdump on the openvpn server while trying to ping 8.8.8.8? – 3molo Feb 15 '11 at 14:49
  • echo-request is sent (as expected), but there is no echo-reply. With OpenVPN turned off on the client, I see an echo-reply as expected. Pinging from my server using SSH, I can see an echo-reply too. – Lekensteyn Feb 15 '11 at 15:57