AWS redundáns IPSec

Sziasztok!

Igen érdekes problémába futottam bele, amivel elakadtam.

A setup: egy Deb 10 (8-ról upgradelve), rajta StongSwan (U5.7.2/K4.19.0-18-amd64) és egy redundáns tunnel pár az AWS felé (policy módban). A gépben 2 NIC: 1 pub és 1 internal. A tunnel leftsubnet az az int-en directly connected. ip_forward=1, iptables OFF, default policy ACCEPT

A probléma: a tunnel-ek szépen up-ban, 'tcpdump -ni any' -vel látszik is, hogy megjönnek a túloldalról a csomagok (most icmp) és dekriptálásra kerülnek, azonban ezek a csomagok már nem kerülnek át az internal nic-re (ens4), hanem szépen elnyelődnek valahol. A kérdés, hogy hol. (a dolgot tovább színezi, hogy egy idő után (t > 15 perc) megjelennek a csomagok az ens4-en (és utána már rendben működik a kapcsolat).

root@ipsec-test:/etc# uname -a
Linux ipsec-test 4.19.0-18-amd64 #1 SMP Debian 4.19.208-1 (2021-09-29) x86_64 GNU/Linux
root@ipsec-test:~# ipsec status
Routed Connections:
AWS_TUN_2{2}:  ROUTED, TUNNEL, reqid 1
AWS_TUN_2{2}:   172.16.1.0/28 === 10.1.8.0/22
AWS_TUN_1{1}:  ROUTED, TUNNEL, reqid 1
AWS_TUN_1{1}:   172.16.1.0/28 === 10.1.8.0/22
Security Associations (2 up, 0 connecting):
AWS_TUN_2[2]: ESTABLISHED 2 seconds ago, MY_PUB_IP[MY_PUB_IP]...AWS_PUB_2[AWS_PUB_2]
AWS_TUN_2{4}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: cb5XXXXX_i cfYYYYYY_o
AWS_TUN_2{4}:   172.16.1.0/28 === 10.1.8.0/22
AWS_TUN_1[1]: ESTABLISHED 5 seconds ago, MY_PUB_IP[MY_PUB_IP]...AWS_PUB_1[AWS_PUB_1]
AWS_TUN_1{3}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: c6eZZZZZ_i c2bWWWWW_o
AWS_TUN_1{3}:   172.16.1.0/28 === 10.1.8.0/22
root@ipsec-test:~# cat /proc/sys/net/ipv4/ip_forward
1
root@ipsec-test:~# tcpdump -nni any net 10.1.8.0/22
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
23:55:12.249212 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11722, length 64
23:55:13.273167 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11723, length 64
23:55:14.297249 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11724, length 64
23:55:15.321273 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11725, length 64
23:55:16.345180 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11726, length 64
23:55:17.369328 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11727, length 64
23:55:18.393192 IP 10.1.11.106 > 172.16.1.6: ICMP echo request, id 14422, seq 11728, length 64
^C
12 packets captured
13 packets received by filter
0 packets dropped by kernel
root@ipsec-test:~# tcpdump -nni ens4 net 10.1.8.0/22
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens4, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
0 packets captured
0 packets received by filter
0 packets dropped by kernel
root@ipsec-test:~#
root@ipsec-test:/etc# ip ro get 172.16.1.0/28
broadcast 172.16.1.0 dev ens4 table local src 172.16.1.1 uid 0
    cache <local,brd>
root@ipsec-test:/etc# ping 172.16.1.6
PING 172.16.1.6 (172.16.1.6) 56(84) bytes of data.
64 bytes from 172.16.1.6: icmp_seq=1 ttl=64 time=0.252 ms
64 bytes from 172.16.1.6: icmp_seq=2 ttl=64 time=0.342 ms
^C
--- 172.16.1.6 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 19ms
rtt min/avg/max/mdev = 0.252/0.297/0.342/0.045 ms
root@ipsec-test:/etc#

A neten túl sok értelmes választ nem kaptam, egy régi thread-et találtam (4+ év), hogy ez a fajta setup nem támogatott. Ezt értem, de mivel a tunnelek rendben összeállnak és van rendben bejövő csomag, ami dekriptálásra is kerül, így ezen most ugorjunk, kérlek. A kérdés, hogy mi a búbánat tűnteti el a csomagokat és hová, illetve, hogy mit lehet tenni ez ellen.