[Solved]Client connects but no internet access

[ryan0270]

My goal is pretty straightforward; I want to tunnel all client traffic through VPN. Establishing the connection is easy enough but the client can no longer access the internet (ping 8.8.8.8 fails). I've been banging my head against this on and off for a few days now with no luck.

Here is what I'm getting on the client computer. First, the route without VPN:

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.50.1    0.0.0.0         UG    202    0        0 eth0
192.168.50.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0

Route after VPN connection (45.33.15.172 is the VPN server address):

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.8.0.13       128.0.0.0       UG    0      0        0 tun0
0.0.0.0         192.168.50.1    0.0.0.0         UG    202    0        0 eth0
10.8.0.1        10.8.0.13       255.255.255.255 UGH   0      0        0 tun0
10.8.0.13       0.0.0.0         255.255.255.255 UH    0      0        0 tun0
45.33.15.172    192.168.50.1    255.255.255.255 UGH   0      0        0 eth0
128.0.0.0       10.8.0.13       128.0.0.0       UG    0      0        0 tun0
192.168.50.0    0.0.0.0         255.255.255.0   U     202    0        0 eth0

And finally pinging first the VPN server then google dns (after VPN connection):

Code: Select all

[] # ping 45.33.15.172
PING 45.33.15.172 (45.33.15.172) 56(84) bytes of data.
64 bytes from 45.33.15.172: icmp_seq=1 ttl=51 time=65.4 ms
64 bytes from 45.33.15.172: icmp_seq=2 ttl=51 time=66.0 ms
64 bytes from 45.33.15.172: icmp_seq=3 ttl=51 time=65.5 ms

--- 45.33.15.172 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 65.423/65.666/66.037/0.398 ms
[] #
[] # ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.

--- 8.8.8.8 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2008ms

server.conf

Code: Select all

port ****
proto udp
dev tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/****.crt
key /etc/openvpn/****.key
dh /etc/openvpn/dh2048.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1"
keepalive 10 120
comp-lzo
user nobody
group nobody
persist-key
persist-tun
status openvpn-status.log
verb 3

To minimize firewall interference I tried to turn everything off and then just enable forwarding (blindly following commands from https://wiki.archlinux.org/index.php/Internet_sharing). I have tried everything with a "normal" firewall as well but same behavior.

Code: Select all

[]# iptables -nvL
Chain INPUT (policy ACCEPT 765 packets, 67440 bytes)
 pkts bytes target     prot opt in     out     source               destination         

Chain FORWARD (policy ACCEPT 8 packets, 672 bytes)
 pkts bytes target     prot opt in     out     source               destination         
   72  6048 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
   25  1924 ACCEPT     all  --  tun0   eth0    0.0.0.0/0            0.0.0.0/0           

Chain OUTPUT (policy ACCEPT 682 packets, 131K bytes)
 pkts bytes target     prot opt in     out     source               destination 

From the same site I also confirmed that ip forwarding is enable on the system

Code: Select all

[] # sysctl -a | grep forwarding
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.dummy0.forwarding = 1
net.ipv4.conf.dummy0.mc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 0
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.gre0.forwarding = 1
net.ipv4.conf.gre0.mc_forwarding = 0
net.ipv4.conf.gretap0.forwarding = 1
net.ipv4.conf.gretap0.mc_forwarding = 0
net.ipv4.conf.ip6_vti0.forwarding = 1
net.ipv4.conf.ip6_vti0.mc_forwarding = 0
net.ipv4.conf.ip6gre0.forwarding = 1
net.ipv4.conf.ip6gre0.mc_forwarding = 0
net.ipv4.conf.ip6tnl0.forwarding = 1
net.ipv4.conf.ip6tnl0.mc_forwarding = 0
net.ipv4.conf.ip_vti0.forwarding = 1
net.ipv4.conf.ip_vti0.mc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.sit0.forwarding = 1
net.ipv4.conf.sit0.mc_forwarding = 0
net.ipv4.conf.teql0.forwarding = 1
net.ipv4.conf.teql0.mc_forwarding = 0
net.ipv4.conf.tun0.forwarding = 1
net.ipv4.conf.tun0.mc_forwarding = 0
net.ipv4.conf.tunl0.forwarding = 1
net.ipv4.conf.tunl0.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.dummy0.forwarding = 1
net.ipv6.conf.eth0.forwarding = 0
net.ipv6.conf.gre0.forwarding = 1
net.ipv6.conf.gretap0.forwarding = 1
net.ipv6.conf.ip6_vti0.forwarding = 1
net.ipv6.conf.ip6gre0.forwarding = 1
net.ipv6.conf.ip6tnl0.forwarding = 1
net.ipv6.conf.ip_vti0.forwarding = 1
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.sit0.forwarding = 1
net.ipv6.conf.teql0.forwarding = 1
net.ipv6.conf.tun0.forwarding = 1
net.ipv6.conf.tunl0.forwarding = 1

[Traffic]

This:

finally pinging first the VPN server then google dns (after VPN connection):
Code:
[] # ping 45.33.15.172
PING 45.33.15.172 (45.33.15.172) 56(84) bytes of data.
64 bytes from 45.33.15.172: icmp_seq=1 ttl=51 time=65.4 ms

does not test your VPN as this route:

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
45.33.15.172    192.168.50.1    255.255.255.255 UGH   0      0        0 eth0

send the ping directly .. not over the VPN.

Try pinging 10.8.0.1 to test your VPN.

To ping 8.8.8.8 over the VPN you need to do nat on the server ..

See this HOWTO:
HOWTO: Routing all client traffic (including web-traffic) through the VPN

[ryan0270]

Pinging 10.8.0.1 works fine.

The link I had in my first post does setup nat. To test again, though, I cleared all iptables rules and ran this command from your link:

Code: Select all

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

but no difference. Pinging 8.8.8.8 still fails.

[Traffic]

use tcpdump on your server and see what the source IP of the pings is.

[ryan0270]

Sorry, I'm not quite sure exactly what your asking. I'm also not familiar with tcpdump so forgive me if I'm way off.

From the server with the client pinging 8.8.8.8 ....

Code: Select all

[] # tcpdump -nS -c2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
08:43:10.456571 IP 45.33.15.172 > 8.8.8.8: ICMP echo request, id 1593, seq 1, length 64
08:43:10.457105 IP 8.8.8.8 > 45.33.15.172: ICMP echo reply, id 1593, seq 1, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel

[Traffic]

It looks like it is working to me:

08:43:10.456571 IP 45.33.15.172 > 8.8.8.8: ICMP echo request, id 1593, seq 1, length 64
08:43:10.457105 IP 8.8.8.8 > 45.33.15.172: ICMP echo reply, id 1593, seq 1, length 64

Try using tcpdump on the tun interface .. pre/post-nat

[ryan0270]

Code: Select all

 [] # tcpdump -nS -c2 icmp -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:44:05.873379 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1707, seq 1, length 64
09:44:06.881022 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1707, seq 2, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel

Am I correct in interpreting this as saying the server sends the ping request out and gets the response but fails to send the response back to the client?

When you say test pre/post-nat do you mean test with the nat turned off and then turned on? Here is the nat turned off

Code: Select all

 [] # tcpdump -nS -c2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:55:24.623777 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1725, seq 1, length 64
09:55:25.632580 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1725, seq 2, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
[] # 
[] #  tcpdump -nS -c2 icmp -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:56:14.887436 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1727, seq 1, length 64
09:56:15.887555 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1727, seq 2, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel

And here is with the nat turned on:

Code: Select all

 [] #  iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
[] # tcpdump -nS -c2 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
09:58:19.758268 IP 45.33.15.172 > 8.8.8.8: ICMP echo request, id 1730, seq 1, length 64
09:58:19.758842 IP 8.8.8.8 > 45.33.15.172: ICMP echo reply, id 1730, seq 1, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel
[] #
[] #tcpdump -nS -c2 icmp -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
09:59:05.688716 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1732, seq 1, length 64
09:59:06.697847 IP 10.8.0.14 > 8.8.8.8: ICMP echo request, id 1732, seq 2, length 64
2 packets captured
2 packets received by filter
0 packets dropped by kernel

[Traffic]

When you say test pre/post-nat do you mean test with the nat turned off and then turned on?

No .. pre=before nat on tun (echo request); post=after nat on tun (echo reply) ..

Is your server a VM or vz container ?

[ryan0270]

Server is a machine running at www.linode.com.

Are there any other commands I should be running to get more information?

[Traffic]

It is possible your Server cannot use Masquerade try this instead:

Code: Select all

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source 45.33.15.172

[ryan0270]

Still no luck I cleared the iptables rules and ran you command but pinging from the client still gives the same behavior when checking with tcpdump.

Am I trying to do something too strange or is there probably some hidden config item somewhere blocking me?

[Traffic]

I presume you understand how NAT works ?

Using tcpdump on each interface (tun/eth) you can see how the source address of the pings from the client (10.8.0.x) is changed to the public IP of the server (45.33.15.172) .. 8.8.8.8 then replies to 45.33.15.172 and the nat on your server should automatically un-nat and transmit the ping reply back to the client.

This is not happening ...

The only suggestion I can give you is to contact your Linux provider linode.com and ask them to look into it .. this is not a problem with OpenVPN.

Somebody else here may be able to help ..

[ryan0270]

I only understand at a high level how most of this stuff is supposed to work. This project is partially a tool to learn more (but also something I want for personal, safe internet access while travelling to e.g. China).

Thanks for all your support so far. I'll talk with linode and if I figure something out I'll come back and post it here.

[Traffic]

A closer look at your "sysctl" settings .. I notice:

Code:
[] # sysctl -a | grep forwarding

net.ipv4.conf.eth0.forwarding = 0

net.ipv6.conf.eth0.forwarding = 0

net.ipv6.conf.tun0.forwarding = 1

Perhaps you should fix that ..

[ryan0270]

Good catch; that appears to be a bug/change in systemd (https://bugs.freedesktop.org/show_bug.cgi?id=89509)

Explicitly setting that and things work. Now I just need to figure out how to make it persist. Thanks again for all your help!