Проблема с NAT с VPN

У меня есть сервер Ubuntu, на котором работает StrongSwan. Я могу успешно подключиться и направить весь трафик через VPN с клиентом для ноутбука и клиентом для iPhone. Что мне нужно сделать, так это подключить маршрутизатор M2M, который работает через 4G. На роутере cat /proc/version дает:

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

Я успешно подключил маршрутизатор к серверу. Однако попытка выполнить любую сетевую команду (кроме доступа к локальной сети) на маршрутизаторе приводит к тайм-ауту или тому подобному. Очевидно, что где-то пакеты не проходят. Я не совсем уверен, проблема ли это в брандмауэре или в маршрутизации. Любая помощь будет принята с благодарностью.

Настройка выглядит следующим образом:

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

Я надеюсь, что сказанное выше имеет смысл. По сути, обе стороны находятся за NAT.

На маршрутизаторе M2M у меня есть следующая информация:

Таблица списка маршрутов IP 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 мобильный интерфейс (т.е. подключается через 4G).

Насколько мне известно, единственное важное правило брандмауэра для маршрутизируемого трафика (т.е.исключение трафика IPSec):

iptables -t nat -L ПОСТРОУТИРОВАНИЕ

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 во время пробежки пинг 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)

локон 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)

думаю 82.132.254.3 что-то связано с моим общедоступным IP-адресом на маршрутизаторе 4G, хотя на самом деле это не тот IP-адрес, который я получаю, когда делаю «какой у меня IP».