OpenVPN: Traffic Redirection not Working

Question

tl;dr (after hours of debugging with @krisFR): At least under Debian 8, never use virtual interfaces (eth0:1) for OpenVPN, instead apply the new debian iproute2 methods (manual approach) described here: https://wiki.debian.org/NetworkConfiguration#iproute2_method . It will route the traffic just well.

I was trying to setup OpenVPN on a machine where all the client traffic should be sent over the tunnel, so this is part of my server config:

local x.x.x.243
port 443
proto udp
dev tun
server 172.31.1.0 255.255.255.0 
push "redirect-gateway def1 bypass-dhcp"

And my client config:

pull
resolv-retry infinite
mute-replay-warnings 
redirect-gateway def1
script-security 1

The client is able to connect to the VPN and it can ping the VPN host at 172.31.1.1, however if I try to ping google.com by domain or IP, I get a Request timeout for icmp_seq 0 message...

What can be causing this? Side note, I've uninstalled any firewall and I'm currently setting IPTables to:

iptables -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 443 -j ACCEPT
iptables -A INPUT -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -j ACCEPT
iptables -A FORWARD -i tun+ -o eth0:1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth0:1 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j MASQUERADE
iptables -A OUTPUT -o tun+ -j ACCEPT

Thank you.

So I tried to ping on the client 213.30.5.46 (one of Google's IPs) and it didn't work, however I got this results:

Listening on the outgoing VPN IP (eth0:1): tcpdump -i eth0 -t host x.x.x.243

IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 113
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP vpn.exampledomain.com.https > [CLIENT_IP x..].51060: UDP, length 81
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145
IP [CLIENT_IP x..].51060 > vpn.exampledomain.com.https: UDP, length 145

At the same time, listening on tun0, I got this: tcpdump -i tun0

23:40:39.864798 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 0, length 64
23:40:40.925951 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 256, length 64
23:40:41.886679 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 512, length 64
23:40:42.906125 IP 172.31.1.10 > cache.google.com: ICMP echo request, id 17942, seq 768, length 64

Here is the output of iptables -L -n -v:

Chain INPUT (policy ACCEPT 34772 packets, 2265K bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     udp  --  eth0:1 *       0.0.0.0/0            0.0.0.0/0            state NEW udp dpt:443
   13  1092 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
 1437 96985 ACCEPT     all  --  tun+   *       0.0.0.0/0            0.0.0.0/0           
    0     0 ACCEPT     all  --  tun+   eth0:1  0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  eth0:1 tun+    0.0.0.0/0            0.0.0.0/0            state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT 32574 packets, 7919K bytes)
 pkts bytes target     prot opt in     out     source               destination         
   13  1092 ACCEPT     all  --  *      tun+    0.0.0.0/0            0.0.0.0/0

Note: /proc/sys/net/ipv4/ip_forward is set to 1.

Targeted tcpdump -i eth0:1 -t host 213.30.5.46 while pinging the destination:

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0:1, link-type EN10MB (Ethernet), capture size 262144 bytes
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 0, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 256, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 512, length 64
IP 172.31.1.10 > cache.google.com: ICMP echo request, id 16920, seq 768, length 64

Nothing shows on the client, ping eventually times out.

The IP address used by OpenVPN local x.x.x.243 is setup on \etc\network\interfaces as eth0:1 right after eth0 as:

 auto eth0:1
  iface eth0:1 inet static
   address x.x.x.243
   gateway x.x.x.129
   netmask 255.255.255.128
   dns-nameservers x.x.x.4 x.x.x.104

Have you tried to use `tcpdump` on `tun+` and `eth0:1` on openvpn server while pinging 8.8.8.8 from a VPN client, to see what could happen ? — krisFR, May 19 '15 at 21:01
Should be the same than masquerade, but we could try `iptables -t nat -A POSTROUTING -s 172.31.1.0/24 -o eth0:1 -j SNAT --to-source x.x.x.243` instead. It is interesting to see that no reply comes back to your external interface...Are you sure your public IP is the correct one...? — krisFR, May 19 '15 at 23:16
Could this issue be related to be using virtual interfaces? eth0:1? — TCB13, May 19 '15 at 23:28
What if you run `tcpdump -n host 213.30.5.46` (no filter on any interface) while pinging ? — krisFR, May 19 '15 at 23:31
I still get `01:32:18.799289 IP 172.31.1.10 > 213.30.5.46: ICMP echo request, id 27417, seq 0, length 64` for each packet sent... — TCB13, May 19 '15 at 23:33
What if you ping 213.30.5.46 directly from the openvpn server ? — krisFR, May 19 '15 at 23:34
Yes, I do get an answer: `64 bytes from 213.30.5.46: icmp_seq=1 ttl=53 time=44.5 ms` — TCB13, May 19 '15 at 23:42
So... Like I was suspecting the virtual interface was screwing us... I replaced the virtual interface definition with the "iproute2" method described here: https://wiki.debian.org/NetworkConfiguration#iproute2_method and suddenly it was working fine. The ip shows on `ip addr` but not on `ifconfig`... — TCB13, May 19 '15 at 23:51
If you write an answer saying not to use virtual interface, and instead use the new debian iproute2 I'm gonna accept it due to the long help and dedication to this! Thanks for everything, you rock sir! — TCB13, May 20 '15 at 00:24

krisFR · Accepted Answer · 2015-05-20T17:50:52.837

As you said, we spend hours together to debug this...

Regarding all tests we have done and all trace we retrieved, it finally appears that we were experiencing some weird behaviours regarding the Virtual Interface eth0:1.

e.g : http://lartc.org/howto/lartc.iproute2.html

Most Linux distributions, and most UNIX's, currently use the venerable arp, ifconfig and route commands. While these tools work, they show some unexpected behaviour under Linux 2.2 and up. For example, GRE tunnels are an integral part of routing these days, but require completely different tools.

With iproute2, tunnels are an integral part of the tool set.

We decided to switch to iproute2 (at least give it a try) modifying /etc/network/interfaces file to change the manner to assign multiple IPs to the eth0 interface.

After that everything went fine and working !

iproute2 example :

auto eth0
allow-hotplug eth0
iface eth0 inet static
    address 192.168.1.42
    netmask 255.255.255.0
    gateway 192.168.1.1

iface eth0 inet static
    address 192.168.1.43
    netmask 255.255.255.0

Further infos about iproute2 here :

OpenVPN: Traffic Redirection not Working

1 Answers1