0

I have the following setup:

  • Dedicated server S with static public IP address on eth0 running OpenVPN as server on tun0 and performing NAT from tun0 to eth0
  • Gateway router G that is the OpenVPN client on tun0 with IP 10.8.0.16

the issue is that I can apparently reach the internet just fine and the responses get back just fine only that the Gateway router just flat out does not accept them back.

See the following example:

TCPdump while pinging 1.1.1.1 on G yields

# ping 1.1.1.1 -I tun0
PING 1.1.1.1 (1.1.1.1) from 10.8.0.16 tun0: 56(84) bytes of data.
♥
--- 1.1.1.1 ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6005ms

# tcpdump -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
05:23:35.781349 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 15, length 64
05:23:35.814670 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 15, length 64
05:23:36.781452 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 16, length 64
05:23:36.826077 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 16, length 64
05:23:37.781352 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 17, length 64
05:23:37.819026 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 17, length 64
05:23:38.781321 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 18, length 64
05:23:38.818058 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 18, length 64
05:23:39.781330 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 19, length 64
05:23:39.813765 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 19, length 64
05:23:40.781333 IP 10.8.0.16 > 1dot1dot1dot1.cloudflare-dns.com: ICMP echo request, id 6803, seq 20, length 64
05:23:40.813766 IP 1dot1dot1dot1.cloudflare-dns.com > 10.8.0.16: ICMP echo reply, id 6803, seq 20, length 64

as you can see the ping reaches 1.1.1.1 just fine and a reply gets back but the output of pingstays silent

Iptables for G:

# iptables-save | grep -v -e DOCKER -e docker
# Generated by iptables-save v1.6.0 on Sat Aug  4 06:00:09 2018
*filter
:INPUT ACCEPT [29125:29954508]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [28322:3971375]
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
COMMIT
# Completed on Sat Aug  4 06:00:09 2018
# Generated by iptables-save v1.6.0 on Sat Aug  4 06:00:09 2018
*nat
:PREROUTING ACCEPT [3840:167985]
:INPUT ACCEPT [110:29389]
:OUTPUT ACCEPT [198:66581]
:POSTROUTING ACCEPT [198:66581]
-A POSTROUTING -s 192.168.0.0/16 -o eth1 -j MASQUERADE
COMMIT
# Completed on Sat Aug  4 06:00:09 2018

tcpdump on S also shows that the ICMP request is forwarded properly:

22:39:44.983332  In ethertype IPv4 (0x0800), length 100: 10.8.0.16 > 1.1.1.1: ICMP echo request, id 5383, seq 3, length 64
22:39:44.983348 Out 00:25:90:82:12:92 ethertype IPv4 (0x0800), length 100: 91.121.133.159 > 1.1.1.1: ICMP echo request, id 5383, seq 3, length 64
22:39:44.989167  In 00:00:5e:00:01:01 ethertype IPv4 (0x0800), length 100: 1.1.1.1 > 91.121.133.159: ICMP echo reply, id 5383, seq 3, length 64
22:39:44.989184 Out ethertype IPv4 (0x0800), length 100: 1.1.1.1 > 10.8.0.16: ICMP echo reply, id 5383, seq 3, length 64

The iptables on S look alright, too:

singinwhale# iptables-save | grep -v -e DOCKER -e docker
# Generated by iptables-save v1.4.21 on Fri Aug  3 23:54:56 2018
*raw
:PREROUTING ACCEPT [134484:12309809]
:OUTPUT ACCEPT [143517:21443183]
COMMIT
# Completed on Fri Aug  3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug  3 23:54:56 2018
*nat
:PREROUTING ACCEPT [11432:503568]
:INPUT ACCEPT [3303:157660]
:OUTPUT ACCEPT [2083:317164]
:POSTROUTING ACCEPT [2083:317164]
-A POSTROUTING -s 10.8.0.0/16 -o eth0 -j MASQUERADE
COMMIT
# Completed on Fri Aug  3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug  3 23:54:56 2018
*mangle
:PREROUTING ACCEPT [134484:12309809]
:INPUT ACCEPT [112991:10911009]
:FORWARD ACCEPT [12383:1034220]
:OUTPUT ACCEPT [143517:21443183]
:POSTROUTING ACCEPT [155157:22421380]
COMMIT
# Completed on Fri Aug  3 23:54:56 2018
# Generated by iptables-save v1.4.21 on Fri Aug  3 23:54:56 2018
*filter
:INPUT ACCEPT [77764:7068235]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [107553:10768547]
-A INPUT -p tcp -m tcp --dport 45454 -j ACCEPT
-A INPUT ! -s 127.0.0.1/32 -p tcp -m tcp --dport 56845 -j DROP
-A FORWARD -i tun0 -o eth0 -j ACCEPT
-A FORWARD -i eth0 -o tun0 -j ACCEPT
COMMIT
# Completed on Fri Aug  3 23:54:56 2018

The same is happening for curl http requests btw so this is not only for ICMP. What is going on here?


EDIT

apparently rp_netfilter is enabled (set to 1) on all interfaces and thus the packets arriving from 1.1.1.1 on tun0 are classified as martians. Thats a start but I never dealt with netfilter before but at least its a start.

Here is my routing table:

My routing table looks like this:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         server.frederix 0.0.0.0         UG    100    0        0 eth1
10.8.0.0        *               255.255.0.0     U     0      0        0 tun0
link-local      *               255.255.0.0     U     1000   0        0 eth0
172.29.8.236    *               255.255.255.252 U     100    0        0 eth1
server.frederix server.frederix 255.255.255.255 UGH   100    0        0 eth1
192.168.0.0     *               255.255.0.0     U     0      0        0 eth0

And here is the output of some commands that @A.B. requested:

root@gateway ~ # ip -br link
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
bond0            DOWN           8e:f6:77:ae:d0:f2 <BROADCAST,MULTICAST,MASTER>
tunl0@NONE       DOWN           0.0.0.0 <NOARP>
sit0@NONE        DOWN           0.0.0.0 <NOARP>
eth0             UNKNOWN        c2:c5:04:7a:0c:ba <BROADCAST,MULTICAST,UP,LOWER_UP>
eth1             UNKNOWN        ba:0b:a9:79:40:5b <BROADCAST,MULTICAST,UP,LOWER_UP>
wlan0            DOWN           00:08:22:4c:b3:fb <BROADCAST,MULTICAST>
tun0             UNKNOWN        <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP>
root@gateway ~ # ip -4 -br address
lo               UNKNOWN        127.0.0.1/8
eth0             UNKNOWN        192.168.0.1/16
eth1             UNKNOWN        172.29.8.237/30
tun0             UNKNOWN        10.8.0.16/16
root@gateway ~ # ip route
default via 172.29.8.238 dev eth1  proto static  metric 100
10.8.0.0/16 dev tun0  proto kernel  scope link  src 10.8.0.16
169.254.0.0/16 dev eth0  scope link  metric 1000
172.29.8.236/30 dev eth1  proto kernel  scope link  src 172.29.8.237  metric 100
172.30.3.254 via 172.29.8.238 dev eth1  proto dhcp  metric 100
192.168.0.0/16 dev eth0  proto kernel  scope link  src 192.168.0.1
root@gateway ~ # ip route get 1.1.1.1
1.1.1.1 via 172.29.8.238 dev eth1  src 172.29.8.237
4
  • Appears to be a routing problem. Can you add in the question the output of ip -br link; ip -4 -br address; ip route and while at it ip route get 1.1.1.1 on G? – A.B Aug 4 '18 at 1:17
  • eth0 may be dropping the traffic because packets coming from 1.1.1.1 probably don't have a route from tun0. Does G have reverse path filter enabled? Debian may enable it by default. You can check: cat /proc/sys/net/ipv4/conf/{all,default,eth0}/rp_filter and permanently adjust the values in /etc/sysctl.conf. Alternatively you can enable logging of traffic dropped by rp_filter by setting /proc/sys/net/ipv4/conf/all/log_martians to 1. – cburn11 Aug 4 '18 at 6:21
  • @cburn11 you are right, martians are logged on tun0: Aug 4 17:54:44 gateway kernel: [59801.726811] IPv4: martian source 10.8.0.16 from 1.1.1.1, on dev tun0 now the question is what do I do about it? I put my routing table in the OP – singinWhale Aug 4 '18 at 9:55
  • If it is only the rp_filter dropping the traffic you can temporarily (won't persist over reboot) disable it by setting /proc/sys/net/ipv4/conf/all/rp_filter to 0 (or to 2 which is a hybrid value that allows traffic as long as there is at least 1 interface that has a route to the source address) so echo 2 > /proc/sys/net/ipv4/conf/all/rp_filter. That will at least solve your rp_filter problem, but that may not be your only problem. You can permanently set rp_filter in /etc/sysctl.conf with net.ipv4.conf.all.rp_filter=(value). – cburn11 Aug 4 '18 at 15:56
0

Your routing table shows that you aren't routing any traffic to the VPN, other than the VPN's own 10.8.0.0/16 network.

If you want the VPN to handle traffic, you need to set up the appropriate routes for that traffic. Otherwise, nothing will go through the VPN.

For instance, to route all traffic through the VPN, your server config should have something like:

push "redirect-gateway ipv6 def1 bypass-dhcp"
2
  • that behaviour is intentional I just want to route traffic for a certain device behind my gateway router there but that is the next step – singinWhale Aug 5 '18 at 16:41
  • You need to set up the routes you want first, and then try to send traffic over them. You have put the cart before the horse here. – Michael Hampton Aug 5 '18 at 16:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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