Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
[SOLVED] Question on VPN + multiple routing tables
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 3:26 pm    Post subject: [SOLVED] Question on VPN + multiple routing tables Reply with quote

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
Code:
iptables -t mangle -A PREROUTING -s 192.168.1.106 -j MARK --set-mark 1


IP rule
Code:
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
Code:
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
Code:
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:

Code:
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:

Code:
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


Code:
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
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 3:58 pm    Post subject: Reply with quote

Code:

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:

Code:
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   

_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 4:44 pm    Post subject: Reply with quote

Thanks!

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

Code:
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 :(

Code:
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
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 4:54 pm    Post subject: Reply with quote

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

Main table
Code:
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
Code:
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:

Code:
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?
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 5:22 pm    Post subject: Reply with quote

Code:
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?
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 5:34 pm    Post subject: Reply with quote

Unfortunately I don't have access to the server.

I've tweaked the settings a little bit:

Main table
Code:
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
Code:
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:

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


Tracepath:

Code:
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:

Code:
# 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
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 5:51 pm    Post subject: Reply with quote

And a tcpdump on the vpn client host?
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 6:31 pm    Post subject: Reply with quote

This is me trying to do a tracepath to 8.8.8.8:

Code:
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.
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 7:45 pm    Post subject: Reply with quote

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:

Code:
work: 10.4.0.0/16 dev tun0  scope link
vs.
Code:
main: 10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.1.2

_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 8:16 pm    Post subject: Reply with quote

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:
Code:

10.4.0.0/16 dev tun0  proto kernel  scope link  src 10.4.0.46


Results are the same.
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 8:45 pm    Post subject: Reply with quote

Code:

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.
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 9:43 pm    Post subject: Reply with quote

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:

Code:
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.

Code:
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
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 10:08 pm    Post subject: Reply with quote

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

 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?
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 10:21 pm    Post subject: Reply with quote

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

Code:
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.
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 10:54 pm    Post subject: Reply with quote

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

Code:
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
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Sun May 15, 2016 10:57 pm    Post subject: Reply with quote

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.
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Sun May 15, 2016 11:10 pm    Post subject: Reply with quote

No worries. Thank you for your help!
Back to top
View user's profile Send private message
dritanm
n00b
n00b


Joined: 15 May 2016
Posts: 11

PostPosted: Mon May 16, 2016 12:27 am    Post subject: Reply with quote

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:

Code:

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


Hopefully this helps someone else that might run into the same issue.
Back to top
View user's profile Send private message
papahuhn
l33t
l33t


Joined: 06 Sep 2004
Posts: 623

PostPosted: Mon May 16, 2016 8:36 am    Post subject: Reply with quote

Interesting, as my rp_filter setting is 0. But I'm glad that it works for you.
_________________
Death by snoo-snoo!
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum