# [SOLVED] Question on VPN + multiple routing tables

## dritanm

Hi guys,

I'm having a bit of a problem with my Gentoo home router setup and am not sure what's going wrong. Hopefully someone here has dealt with this before and help me out.

Network overview

Internet => Cable modem (192.168.0.1) => Gentoo server (192.168.0.2 / 192.168.1.1) => Subnet A (192.168.1.0/24)

All the devices in the flat connects to the subnet A. The Gentoo server also has an openvpn instance that is connected to my work's network at 10.4.0.0/16. I don't want all the traffic to go through VPN, but only one work device (192.168.1.106) should be tunneled through VPN. I plan to achieve this with a combination of iptables + iproute2. The traffic from the work device is marked by iptables and I've created a separate routing table using iproute2, which should capture the work device traffic and route them through this table.

Current setup

IPTABLES

```
iptables -t mangle -A PREROUTING -s 192.168.1.106 -j MARK --set-mark 1
```

IP rule

```
ip rule show

0:      from all lookup local

32765:  from all fwmark 0x1 lookup work

32766:  from all lookup main

32767:  from all lookup default

```

Main routing table

```
ip route show

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

128.0.0.0/1 via 10.4.0.1 dev tun0

192.168.0.0/24 dev enp2s0  proto kernel  scope link  src 192.168.0.2

192.168.1.0/24 dev enp0s16f0u2  proto kernel  scope link  src 192.168.1.1

```

Work routing table

```
ip route show table work

0.0.0.0/1 via 10.4.0.1 dev tun0

10.4.0.1 dev tun0  proto kernel  scope link  src 10.4.1.2

1.2.3.4 via 192.168.0.1 dev enp2s0

127.0.0.0/8 dev lo  scope host

128.0.0.0/1 via 10.4.0.1 dev tun0

192.168.0.0/24 dev enp2s0  proto kernel  scope link  src 192.168.0.2

192.168.1.0/24 dev enp0s16f0u2  proto kernel  scope link  src 192.168.1.1

```

As you can see, the VPN gateway of 10.4.0.1 is the default gateway of the work routing table. The public facing IP of the VPN server is 1.2.3.4. However, under this set up, the work device cannot get pass the VPN gateway:

```
tracepath smtp.work.com

 1?: [LOCALHOST]                                         pmtu 1500

 1:  10.4.0.1                                            109.652ms

 1:  10.4.0.1                                            101.206ms

 2:  no reply

 3:  no reply

```

If I change the default route on the main routing table so that the entire network uses the VPN, then it works:

```
ip route show

0.0.0.0/1 via 10.4.0.1 dev tun0

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

1.2.3.4 via 192.168.0.1 dev enp2s0

127.0.0.0/8 dev lo  scope host

128.0.0.0/1 via 10.4.0.1 dev tun0

192.168.0.0/24 dev enp2s0  proto kernel  scope link  src 192.168.0.2

192.168.1.0/24 dev enp0s16f0u2  proto kernel  scope link  src 192.168.1.1

```

```
tracepath smtp.work.com

 1?: [LOCALHOST]                                         pmtu 1500

 1:  10.4.0.1                                            103.273ms

 1:  10.4.0.1                                             98.892ms

 2:  10.110.0.1                                          111.949ms

 3:  212.111.33.233                                      113.341ms

 4:  85.90.238.69                                        114.286ms asymm  6

```

So this leads me to believe that the iptables setup is correct, the VPN is correctly set up, but the problem lies with iproute2. Has anyone managed to get a similar setup to work before?

Thank you!Last edited by dritanm on Mon May 16, 2016 12:28 am; edited 1 time in total

----------

## papahuhn

```

1.2.3.4 via 192.168.0.1 dev enp2s0

```

 *Quote:*   

> Put that in the main table.

  Forget that, it is covered by the default route. However, it should not be in the work table either. I have a similar, working setup:

```
root@himbeere:~# iptables -t mangle -L PREROUTING -n

Chain PREROUTING (policy ACCEPT)

target     prot opt source               destination         

MARK       all  --  192.168.43.0/24      0.0.0.0/0            MARK set 0x29a

root@himbeere:~# ip rule show

0:   from all lookup local 

32765:   from all fwmark 0x29a lookup 666 

32766:   from all lookup main 

32767:   from all lookup default 

root@himbeere:~# ip route show table 666

default via 10.10.11.1 dev tun0 

192.168.0.0/24 dev eth0  scope link 

192.168.42.0/24 dev wlan0  scope link 

192.168.43.0/24 dev wlan1  scope link 

root@himbeere:~# iptables -t nat -L POSTROUTING -n

Chain POSTROUTING (policy ACCEPT)

target     prot opt source               destination         

MASQUERADE  all  --  0.0.0.0/0           !192.168.42.0/24    

```

----------

## dritanm

Thanks!

I tried that, and now the main routing table looks like:

```
ip route show

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

1.2.3.4 via 192.168.0.1 dev enp2s0

192.168.0.0/24 dev enp2s0  proto kernel  scope link  src 192.168.0.2

192.168.1.0/24 dev enp0s16f0u2  proto kernel  scope link  src 192.168.1.1

```

However, still can't get to anywhere from the work device  :Sad: 

```
tracepath 8.8.8.8

 1?: [LOCALHOST]                                         pmtu 1500

 1:  10.4.0.1                                             87.282ms

 1:  10.4.0.1                                             88.602ms

 2:  no reply

 3:  no reply

```

----------

## dritanm

Removing the 1.2.3.4 didn't work either. Here's the current setup:

Main table

```
ip route show

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

192.168.0.0/24 dev enp2s0  proto kernel  scope link  src 192.168.0.2

192.168.1.0/24 dev enp0s16f0u2  proto kernel  scope link  src 192.168.1.1
```

Work table

```
ip route show table work

default via 10.4.0.1 dev tun0

10.4.0.0/16 dev tun0  scope link

192.168.0.0/24 dev enp2s0  scope link

192.168.1.0/24 dev enp0s16f0u2  scope link

```

My masquerade rules are slightly different. I have the tun0 device in addition to the normal EXTIF:

```
iptables -t nat -L POSTROUTING -n -v

Chain POSTROUTING (policy ACCEPT 546 packets, 47926 bytes)

 pkts bytes target     prot opt in     out     source               destination

  451 57519 MASQUERADE  all  --  *      enp2s0  0.0.0.0/0            0.0.0.0/0

  726  134K MASQUERADE  all  --  *      tun0    0.0.0.0/0            0.0.0.0/0

```

Would you mind posting your main routing table?

----------

## papahuhn

```
pi@himbeere ~ $ ip route show

default via 192.168.0.1 dev eth0 

192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.64 

192.168.43.0/24 dev wlan1  proto kernel  scope link  src 192.168.43.1 

```

Can you do a tcpdump on the vpn server?

----------

## dritanm

Unfortunately I don't have access to the server.

I've tweaked the settings a little bit：

Main table

```
ip route show

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

1.2.3.4 via 192.168.0.1 dev enp2s0

192.168.0.0/24 dev enp2s0  scope link

192.168.1.0/24 dev enp0s16f0u2  scope link

```

Work table

```
ip route show table work

0.0.0.0/1 via 10.4.0.1 dev tun0

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  scope link

128.0.0.0/1 via 10.4.0.1 dev tun0

1.2.3.4 via 192.168.0.1 dev enp2s0

192.168.0.0/24 dev enp2s0  scope link

192.168.1.0/24 dev enp0s16f0u2  scope link

```

I've added a flag to the Google DNS for testing:

```
iptables -t mangle -A OUTPUT -d 8.8.8.8 -j MARK --set-mark 1
```

Tracepath:

```
tracepath 8.8.8.8

 1?: [LOCALHOST]                                         pmtu 1500

 1:  10.4.0.1                                             97.092ms

 1:  10.4.0.1                                             90.647ms

 2:  no reply

 3:  no reply

```

Changing the default route on the main table:

```
# ip route add 0.0.0.0/1 via 10.4.0.1

# ip route add 128.0.0.0/1 via 10.4.0.1

# ip route show

0.0.0.0/1 via 10.4.0.1 dev tun0

default via 192.168.0.1 dev enp2s0  metric 2

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

128.0.0.0/1 via 10.4.0.1 dev tun0

1.2.3.4 via 192.168.0.1 dev enp2s0

192.168.0.0/24 dev enp2s0  scope link

192.168.1.0/24 dev enp0s16f0u2  scope link

# tracepath 8.8.8.8

 1?: [LOCALHOST]                                         pmtu 1500

 1:  10.4.0.1                                             94.772ms

 1:  10.4.0.1                                             98.321ms

 2:  no.rdns-yet.ukservers.com                            91.025ms

 3:  xe-0-0-1.rt0.tcx.ukservers.com                       94.909ms

 4:  xe-0-0-3.rt0.the.ukservers.com                       97.742ms

```

Bizarre...

EDIT:

I should add the following:

Kernel: 4.4.6-gentoo

iproute2: 4.4.0

iptables: 1.4.21-r1

----------

## papahuhn

And a tcpdump on the vpn client host?

----------

## dritanm

This is me trying to do a tracepath to 8.8.8.8:

```
tcpdump -n -i tun0

dropped privs to tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes

14:26:29.728414 IP 10.4.0.46.44642 > 8.8.8.8.44444: UDP, length 1472

14:26:29.826821 IP 10.4.0.1 > 10.4.0.46: ICMP time exceeded in-transit, length 556

14:26:29.828674 IP 10.4.0.46.44642 > 8.8.8.8.44445: UDP, length 1472

14:26:29.916536 IP 10.4.0.1 > 10.4.0.46: ICMP time exceeded in-transit, length 556

14:26:29.917470 IP 10.4.0.46.44642 > 8.8.8.8.44446: UDP, length 1472

14:26:30.007887 IP 94.229.74.89 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:30.918721 IP 10.4.0.46.44642 > 8.8.8.8.44447: UDP, length 1472

14:26:31.007782 IP 94.229.74.89 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:31.920119 IP 10.4.0.46.44642 > 8.8.8.8.44448: UDP, length 1472

14:26:32.007592 IP 94.229.74.89 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:32.921513 IP 10.4.0.46.44642 > 8.8.8.8.44449: UDP, length 1472

14:26:33.013313 IP 185.17.24.65 > 10.4.0.46: ICMP time exceeded in-transit, length 148

14:26:33.922840 IP 10.4.0.46.44642 > 8.8.8.8.44450: UDP, length 1472

14:26:34.016646 IP 185.17.24.65 > 10.4.0.46: ICMP time exceeded in-transit, length 148

14:26:34.924159 IP 10.4.0.46.44642 > 8.8.8.8.44451: UDP, length 1472

14:26:35.026640 IP 78.110.166.97 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:35.925544 IP 10.4.0.46.44642 > 8.8.8.8.44452: UDP, length 1472

14:26:36.926873 IP 10.4.0.46.44642 > 8.8.8.8.44453: UDP, length 1472

14:26:37.928207 IP 10.4.0.46.44642 > 8.8.8.8.44454: UDP, length 1472

14:26:38.034110 IP 78.110.166.94 > 10.4.0.46: ICMP time exceeded in-transit, length 36

20 packets captured

20 packets received by filter

0 packets dropped by kernel

```

Looks like it manages to go beyond 10.4.0.1, but the response from the external servers seem to be timing out. Let me know if you'd like more verbose output.

----------

## papahuhn

What is 10.4.0.46? One of your 10.4.0.0/16 routing entries suggests that tun0's address is 10.4.1.2. Also, they differ in main and work table:

```
work: 10.4.0.0/16 dev tun0  scope link
```

 vs. 

```
main: 10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2
```

----------

## dritanm

10.4.0.46 is the IP address of tun0. I get a new one in the 10.4.0.0/16 range every time I reconnect to the VPN. I had 10.4.1.2 in the initial example so I've been using that in my posts here. I didn't change the tcpdump output manually as there were too many instances.

Both work and main table show this for the link to the VPN subnet now:

```

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.0.46
```

Results are the same.

----------

## papahuhn

```

14:26:31.007782 IP 94.229.74.89 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:33.013313 IP 185.17.24.65 > 10.4.0.46: ICMP time exceeded in-transit, length 148

14:26:35.026640 IP 78.110.166.97 > 10.4.0.46: ICMP time exceeded in-transit, length 36

14:26:38.034110 IP 78.110.166.94 > 10.4.0.46: ICMP time exceeded in-transit, length 36

```

Can you tcpdump on the any interface, please? I'd like to know what happens with those packets after they come in through tun0. I wonder if they get dropped or maybe masqueraded again before they reach 192.168.1.106.

----------

## dritanm

See below. I've tried to turn off as many things that might use the internet, but there will still be some noise in here as this is the main gateway to the internet.

Here is what I think a complete cycle for a tracepath reques:

```
17:34:33.329770 IP 10.4.0.127.58317 > 8.8.8.8.44444: UDP, length 1472

17:34:33.330083 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:33.330108 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:33.428792 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 629

17:34:33.429173 IP 10.4.0.1 > 10.4.0.127: ICMP time exceeded in-transit, length 556
```

185.103.96.130 is the IP of the VPN server. See below for the full tcpdump for about 10 seconds of traffic whilst running tracepath.

```
tcpdump -n -i any not port 22

dropped privs to tcpdump

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

17:34:33.329770 IP 10.4.0.127.58317 > 8.8.8.8.44444: UDP, length 1472

17:34:33.330083 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:33.330108 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:33.428792 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 629

17:34:33.429173 IP 10.4.0.1 > 10.4.0.127: ICMP time exceeded in-transit, length 556

17:34:33.430632 IP 127.0.0.1.48438 > 127.0.0.1.53: 33623+ PTR? 1.0.4.10.in-addr.arpa. (39)

17:34:33.430774 IP 127.0.0.1.53 > 127.0.0.1.48438: 33623 NXDomain* 0/1/0 (98)

17:34:33.431022 IP 10.4.0.127.58317 > 8.8.8.8.44445: UDP, length 1472

17:34:33.431227 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:33.431252 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:33.528700 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 629

17:34:33.529084 IP 10.4.0.1 > 10.4.0.127: ICMP time exceeded in-transit, length 556

17:34:33.529577 IP 127.0.0.1.41731 > 127.0.0.1.53: 55086+ PTR? 1.0.4.10.in-addr.arpa. (39)

17:34:33.529725 IP 127.0.0.1.53 > 127.0.0.1.41731: 55086 NXDomain* 0/1/0 (98)

17:34:33.529953 IP 10.4.0.127.58317 > 8.8.8.8.44446: UDP, length 1472

17:34:33.530139 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:33.530163 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:33.534715 IP 192.168.1.110.56557 > 10.27.32.31.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534762 IP 192.168.0.2.56557 > 10.27.32.31.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534774 IP 192.168.1.110.56557 > 10.27.37.56.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534795 IP 192.168.0.2.56557 > 10.27.37.56.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534804 IP 192.168.1.110.56557 > 10.27.13.156.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534823 IP 192.168.0.2.56557 > 10.27.13.156.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.534833 IP 192.168.1.110.56557 > 10.27.37.57.161:  GetRequest(63)  .1.3.6.1.2.1.25.3.2.1.5.1 .1.3.6.1.2.1.25.3.5.1.1.1 .1.3.6.1.2.1.25.3.5.1.2.1

17:34:33.548531 IP 207.237.20.195 > 192.168.0.2: ICMP net 10.27.32.31 unreachable, length 76

17:34:33.548629 IP 207.237.20.195 > 192.168.1.110: ICMP net 10.27.32.31 unreachable, length 76

17:34:33.558706 IP 207.237.20.195 > 192.168.0.2: ICMP net 10.27.12.106 unreachable, length 76

17:34:33.558800 IP 207.237.20.195 > 192.168.1.110: ICMP net 10.27.12.106 unreachable, length 76

17:34:33.617660 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:33.618034 IP 94.229.74.89 > 10.4.0.127: ICMP time exceeded in-transit, length 36

17:34:34.174411 3d:ef:1b:ef:00:00 > 00:01:00:06:98:6b, RRCP-0x23 query

17:34:34.531460 IP 10.4.0.127.58317 > 8.8.8.8.44447: UDP, length 1472

17:34:34.531799 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:34.531826 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:34.662871 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:34.663207 IP 94.229.74.89 > 10.4.0.127: ICMP time exceeded in-transit, length 36

17:34:35.473048 IP 192.168.0.2.57812 > 193.2.78.228.123: NTPv4, Client, length 48

17:34:35.473120 IP 192.168.0.2.33713 > 78.156.103.10.123: NTPv4, Client, length 48

17:34:35.532792 IP 10.4.0.127.58317 > 8.8.8.8.44448: UDP, length 1472

17:34:35.533164 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:35.533194 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:35.587195 IP 78.156.103.10.123 > 192.168.0.2.33713: NTPv4, Server, length 48

17:34:35.588482 IP 193.2.78.228.123 > 192.168.0.2.57812: NTPv4, Server, length 48

17:34:35.628741 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:35.629104 IP 94.229.74.89 > 10.4.0.127: ICMP time exceeded in-transit, length 36

17:34:35.814058 ARP, Request who-has 192.168.1.1 (3c:18:a0:05:f0:e6) tell 192.168.1.110, length 46

17:34:35.814123 ARP, Reply 192.168.1.1 is-at 3c:18:a0:05:f0:e6, length 28

17:34:36.174554 3d:ef:1b:ef:00:00 > 00:01:00:06:98:6b, RRCP-0x23 query

17:34:36.534186 IP 10.4.0.127.58317 > 8.8.8.8.44449: UDP, length 1472

17:34:36.534514 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:36.534548 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:36.646008 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:36.646343 IP 78.110.166.97 > 10.4.0.127: ICMP time exceeded in-transit, length 36

17:34:37.402705 IP 192.168.1.106.36123 > 4.26.228.253.80: Flags [S], seq 977978410, win 5840, options [mss 1460,sackOK,TS val 768632 ecr 0], length 0

17:34:37.402809 IP 10.4.0.127.36123 > 4.26.228.253.80: Flags [S], seq 977978410, win 5840, options [mss 1460,sackOK,TS val 768632 ecr 0], length 0

17:34:37.403155 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, length 101

17:34:37.492752 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:37.493149 IP 4.26.228.253.80 > 10.4.0.127.36123: Flags [S.], seq 1982764250, ack 977978411, win 5792, options [mss 1352,sackOK,TS val 3344108394 ecr 766527], length 0

17:34:37.535468 IP 10.4.0.127.58317 > 8.8.8.8.44450: UDP, length 1472

17:34:37.535792 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:37.535823 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:37.608714 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:37.609112 IP 4.26.228.253.80 > 10.4.0.127.36123: Flags [S.], seq 1982764250, ack 977978411, win 5792, options [mss 1352,sackOK,TS val 3344108510 ecr 766527], length 0

17:34:37.627522 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 213

17:34:37.627857 IP 185.17.24.65 > 10.4.0.127: ICMP time exceeded in-transit, length 148

17:34:38.174521 3d:ef:1b:ef:00:00 > 00:01:00:06:98:6b, RRCP-0x23 query

17:34:38.536792 IP 10.4.0.127.58317 > 8.8.8.8.44451: UDP, length 1472

17:34:38.537320 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:38.537350 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:38.630197 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:38.630533 IP 78.110.166.97 > 10.4.0.127: ICMP time exceeded in-transit, length 36

17:34:39.538179 IP 10.4.0.127.58317 > 8.8.8.8.44452: UDP, length 1472

17:34:39.538493 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:39.538522 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:40.174656 3d:ef:1b:ef:00:00 > 00:01:00:06:98:6b, RRCP-0x23 query

17:34:40.539508 IP 10.4.0.127.58317 > 8.8.8.8.44453: UDP, length 1472

17:34:40.539825 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:40.539858 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:41.540832 IP 10.4.0.127.58317 > 8.8.8.8.44454: UDP, length 1472

17:34:41.541238 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:41.541269 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:42.174716 3d:ef:1b:ef:00:00 > 00:01:00:06:98:6b, RRCP-0x23 query

17:34:42.542182 IP 10.4.0.127.58317 > 8.8.8.8.44455: UDP, length 1472

17:34:42.542489 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:42.542521 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

17:34:42.990763 IP 192.168.1.106.47172 > 192.168.1.1.53: 14997+ A? secure.footprint.net. (38)

17:34:42.991140 IP 192.168.1.1.53 > 192.168.1.106.47172: 14997 3/0/0 A 8.26.223.253, A 207.123.57.125, A 4.26.228.253 (86)

17:34:42.992188 IP 192.168.1.106.40860 > 207.123.57.125.80: Flags [S], seq 2640405731, win 5840, options [mss 1460,sackOK,TS val 769190 ecr 0], length 0

17:34:42.992251 IP 10.4.0.127.40860 > 207.123.57.125.80: Flags [S], seq 2640405731, win 5840, options [mss 1460,sackOK,TS val 769190 ecr 0], length 0

17:34:42.992461 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, length 101

17:34:43.098871 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

17:34:43.099210 IP 207.123.57.125.80 > 10.4.0.127.40860: Flags [S.], seq 3990629555, ack 2640405732, win 14480, options [mss 1352,sackOK,TS val 2050467633 ecr 769190], length 0

17:34:43.543503 IP 10.4.0.127.58317 > 8.8.8.8.44456: UDP, length 1472

17:34:43.544039 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, bad length 1557 > 1472

17:34:43.544068 IP 192.168.0.2 > 185.103.96.130: ip-proto-17

95 packets captured

110 packets received by filter

11 packets dropped by kernel

```

----------

## papahuhn

I don't see any relevant packets from 192.168.1.106,  just those:

```

 17:34:37.402705 IP 192.168.1.106.36123 > 4.26.228.253.80: Flags [S], seq 977978410, win 5840, options [mss 1460,sackOK,TS val 768632 ecr 0], length 0 

 17:34:42.990763 IP 192.168.1.106.47172 > 192.168.1.1.53: 14997+ A? secure.footprint.net. (38) 

 17:34:42.991140 IP 192.168.1.1.53 > 192.168.1.106.47172: 14997 3/0/0 A 8.26.223.253, A 207.123.57.125, A 4.26.228.253 (86) 

 17:34:42.992188 IP 192.168.1.106.40860 > 207.123.57.125.80: Flags [S], seq 2640405731, win 5840, options [mss 1460,sackOK,TS val 769190 ecr 0], length 0 

```

Did you rather do a tracepath on the VPN client host instead?

----------

## dritanm

Yes I did the tracepath on the VPN client/Gentoo router. I added the following rule to iptables:

```
iptables -t mangle -A OUTPUT -d 8.8.8.8 -j MARK --set-mark 1
```

This should intercept all traffic to 8.8.8.8 and route them through the work table. The work device is a heavily locked down windows laptop with no shell access or utilities I can use to debug.

----------

## dritanm

I turned on the 192.168.1.106, and think I captured a set of requests in the tcpdump log:

```
18:42:43.564657 IP 192.168.1.106.34033 > 192.168.1.1.53: 41577+ A? secure.footprint.net. (38)

18:42:43.565009 IP 192.168.1.1.53 > 192.168.1.106.34033: 41577 3/0/0 A 8.26.223.253, A 4.26.228.253, A 207.123.57.125 (86)

18:42:43.565913 IP 192.168.1.106.41110 > 207.123.57.125.80: Flags [S], seq 576787124, win 5840, options [mss 1460,sackOK,TS val 1177242 ecr 0], length 0

18:42:43.565971 IP 10.4.0.127.41110 > 207.123.57.125.80: Flags [S], seq 576787124, win 5840, options [mss 1460,sackOK,TS val 1177242 ecr 0], length 0

18:42:43.566203 IP 192.168.0.2.55409 > 185.103.96.130.443: UDP, length 101

18:42:43.661948 IP 185.103.96.130.443 > 192.168.0.2.55409: UDP, length 101

18:42:43.662249 IP 207.123.57.125.80 > 10.4.0.127.41110: Flags [S.], seq 4001073300, ack 576787125, win 14480, options [mss 1352,sackOK,TS val 2053921121 ecr 1177242], length 0

```

----------

## papahuhn

Sorry, I don't know how to debug this further. You get the ICMP responses back to your VPN client host, but they don't reach the tracepath process. It works in my setup, though, so no idea.

----------

## dritanm

No worries. Thank you for your help!

----------

## dritanm

papahuhn - 

Thanks for your hint. It seems like the packets were indeed coming back to the router, but they weren't being accepted. A bit of googling led me to this post. The solution turned out to be this line:

```

sysctl -w net.ipv4.conf.tun0.rp_filter=2
```

Hopefully this helps someone else that might run into the same issue.

----------

## papahuhn

Interesting, as my rp_filter setting is 0. But I'm glad that it works for you.

----------

