View previous topic :: View next topic |
Author |
Message |
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 3:26 pm Post subject: [SOLVED] Question on VPN + multiple routing tables |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 3:58 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 4:44 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 4:54 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 5:22 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 5:34 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 5:51 pm Post subject: |
|
|
And a tcpdump on the vpn client host? _________________ Death by snoo-snoo! |
|
Back to top |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 6:31 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 7:45 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 8:16 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 8:45 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 9:43 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 10:08 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 10:21 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 10:54 pm Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Sun May 15, 2016 10:57 pm Post subject: |
|
|
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 |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Sun May 15, 2016 11:10 pm Post subject: |
|
|
No worries. Thank you for your help! |
|
Back to top |
|
|
dritanm n00b
Joined: 15 May 2016 Posts: 11
|
Posted: Mon May 16, 2016 12:27 am Post subject: |
|
|
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 |
|
|
papahuhn l33t
Joined: 06 Sep 2004 Posts: 626
|
Posted: Mon May 16, 2016 8:36 am Post subject: |
|
|
Interesting, as my rp_filter setting is 0. But I'm glad that it works for you. _________________ Death by snoo-snoo! |
|
Back to top |
|
|
|
|
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
|
|