NAT Issue with VPN

nat;routingstrongswan

I've got an Ubuntu server running StrongSwan. I can successfully connect and route all traffic over the VPN with a laptop client and iPhone client. What I need to do is connect an M2M router which operates over 4G. On the router, cat /proc/version gives:

Linux version 3.18.29 (denty@denty-VirtualBox) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r49294) ) #1280 Thu Jan 4 11:40:42 CST 2018

I've successfully connected the router to the server. However, trying to do any network command (except access the local network) on the router results in a timeout or similar. So obviously, somewhere, the packets aren't making it through. I'm not entirely sure whether it's a firewall issue, or a routing issue. Any help would be greatly appreciated.

The setup is as follows:

VPN Server (DO) -> Gateway      -> INTERNET -> Gateway           -> M2M Router
10.16.0.5       -> 10.16.0.1/16 ->          -> 10.169.0.208/27   -> 192.168.8.0/24

I hope the above makes sense. Essentially both sides are behind NAT.

On the M2M Router I have the following info:

ip route list table 220

default via 10.169.0.193 dev usb0  proto static  src 10.11.12.1
10.11.12.1 dev br-lan  scope link
192.168.8.0/24 dev br-lan  proto static  src 192.168.8.1

usb0 is the mobile interface (i.e. connects over 4G).

As far as I'm aware, the only important firewall rule for traffic being routed (i.e. excluding the IPSec traffic) is:

iptables -t nat -L POSTROUTING

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere             policy match dir out pol ipsec
delegate_postrouting  all  --  anywhere             anywhere

tcpdump -i usb0 while running ping 8.8.8.8*

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on usb0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:32:29.712642 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 8, length 64
21:32:30.430582 IP 10.11.12.1.35177 > 82.132.254.2.domain: 7495+ PTR? 8.8.8.8.in-addr.arpa. (38)
21:32:30.430802 IP 10.11.12.1.35177 > 82.132.254.3.domain: 7495+ PTR? 8.8.8.8.in-addr.arpa. (38)
21:32:30.712922 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 9, length 64
21:32:31.713201 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 10, length 64
21:32:32.713480 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 11, length 64
21:32:33.713759 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 12, length 64
21:32:34.714038 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 13, length 64
21:32:35.436038 IP 10.11.12.1.31236 > 82.132.254.3.domain: 62349+ PTR? 8.8.8.8.in-addr.arpa. (38)
21:32:35.714318 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 14, length 64
21:32:36.714637 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 15, length 64
21:32:37.714936 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 16, length 64
21:32:38.715215 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 17, length 64
21:32:39.715495 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 18, length 64
21:32:40.437134 IP 10.11.12.1.65532 > 82.132.254.3.domain: 54142+ PTR? 8.8.8.8.in-addr.arpa. (38)
21:32:40.715774 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 19, length 64
21:32:41.716073 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 20, length 64
21:32:42.716272 ARP, Request who-has 10.169.0.193 tell 10.169.0.208, length 28
21:32:42.716492 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 21, length 64
21:32:42.727952 ARP, Reply 10.169.0.193 is-at 4c:54:99:45:e5:d5 (oui Unknown), length 46
21:32:43.716772 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 22, length 64
21:32:44.717051 IP 10.11.12.1 > 8.8.8.8: ICMP echo request, id 31561, seq 23, length 64
21:32:45.442990 IP 10.11.12.1.32988 > 82.132.254.3.domain: 22720+ PTR? 2.254.132.82.in-addr.arpa. (43)

curl icanhazip.com

curl: (6) Couldn't resolve host 'icanhazip.com'

tcpdump -i usb0

21:33:45.129251 IP 10.11.12.1.44361 > 82.132.254.3.domain: 29320+ AAAA? icanhazip.com. (31)
21:33:47.513230 IP 10.169.0.208.4500 > VPN_SERVER.4500: isakmp-nat-keep-alive
21:33:50.134888 IP 10.11.12.1.32404 > 82.132.254.2.domain: 63895+ AAAA? icanhazip.com. (31)
21:33:50.135128 IP 10.11.12.1.32404 > 82.132.254.3.domain: 63895+ AAAA? icanhazip.com. (31)
21:33:55.137265 IP 10.11.12.1.40502 > 82.132.254.3.domain: 45129+ AAAA? icanhazip.com. (31)
21:34:00.142802 IP 10.11.12.1.10272 > 82.132.254.3.domain: 43791+ A? icanhazip.com. (31)
21:34:01.311002 IP 10.169.0.208.4500 > VPN_SERVER.4500: NONESP-encap: isakmp: child_sa  inf2[I]
21:34:01.368482 IP VPN_SERVER.4500 > 10.169.0.208.4500: NONESP-encap: isakmp: child_sa  inf2[R]
21:34:03.064441 IP 10.169.0.208.22808 > 82.132.254.3.domain: 51862+ AAAA? nrlx.co.uk. (28)
21:34:03.109441 IP 82.132.254.3.domain > 10.169.0.208.22808: 51862 0/1/0 (86)
21:34:03.304161 IP 10.169.0.208.isakmp > VPN_SERVER.isakmp: isakmp: parent_sa ikev2_init[I]
21:34:03.362581 IP VPN_SERVER.isakmp > 10.169.0.208.isakmp: isakmp: parent_sa ikev2_init[R]
21:34:03.612460 IP 10.169.0.208.4500 > VPN_SERVER.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[I]
21:34:03.680580 IP VPN_SERVER.4500 > 10.169.0.208.4500: NONESP-encap: isakmp: child_sa  ikev2_auth[R]
21:34:05.147220 IP 10.11.12.1.29139 > 82.132.254.3.domain: 17183+ A? icanhazip.com. (31)
21:34:10.152697 IP 10.11.12.1.2191 > 82.132.254.3.domain: 2358+ A? icanhazip.com. (31)

I think 82.132.254.3 is something to do with my public IP on the 4G router, although not actually the same IP I get when I do "what's my ip".

Best Answer

Think about those routing tables at 10.169.0.193 device, which typically look like:

default         via Internet
10.169.0.192/27 via 10.169.0.193

The source IP 10.11.12.1 talks to destination 10.169.0.193. Think about the response. Per the routing table it goes... to the Internet. To die there, alone.

You need to NAT it neatly, so that routing table only sees 10.169.0.192/27 coming from your side.

Related Topic