Packets routed via wrong SA
-
Using pfSense 2.2 I have the following setup:
A phase 1 tunnel with a remote site.
Two phase 2 SAs for the following subnets:
Local 172.16.61.5/32 <> Remote 10.45.69.151/32
Local 172.16.60.24/32 <> Remote 192.168.180.161/32For some reason packets meant to go over one SA are routed via the other SA and vice versa:
# ipsec status con4000[4]: ESTABLISHED 29 minutes ago, x.x.x.x[x.x.x.x]...x.x.x.x[x.x.x.x] con4000{2}: INSTALLED, TUNNEL, ESP SPIs: c45bc3ea_i af344699_o con4000{2}: 172.16.61.5/32|/0 === 10.45.69.151/32|/0 con4001{2}: INSTALLED, TUNNEL, ESP SPIs: c1a12a27_i e4d9e8a3_o con4001{2}: 172.16.60.24/32|/0 === 192.168.180.161/32|/0# tcpdump -i enc0 host 172.16.61.5 tcpdump: WARNING: enc0: no IPv4 address assigned tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on enc0, link-type ENC (OpenBSD encapsulated IP), capture size 65535 bytes 12:29:14.393601 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60836: Flags [S.], seq 3422383654, ack 2309105762, win 5840, options [mss 1460], length 0 12:29:15.593016 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60841: Flags [S.], seq 3457032375, ack 463644671, win 5840, options [mss 1460], length 0 12:29:18.191782 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60845: Flags [S.], seq 3462681080, ack 2062812969, win 5840, options [mss 1460], length 0 12:29:18.391628 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60837: Flags [S.], seq 3435472588, ack 2304079740, win 5840, options [mss 1460], length 0 12:29:18.391684 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60844: Flags [S.], seq 3472207278, ack 2848317998, win 5840, options [mss 1460], length 0 12:29:19.008005 (authentic,confidential): SPI 0xc45bc3ea: IP 10.45.69.151.60846 > 172.16.61.5.5402: Flags [s], seq 2813245398, win 65535, options [mss 1460], length 0 12:29:19.008286 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60846: Flags [S.], seq 3468957011, ack 2813245399, win 5840, options [mss 1460], length 0 12:29:21.190329 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60842: Flags [S.], seq 3449808325, ack 781635331, win 5840, options [mss 1460], length 0 12:29:22.789596 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60846: Flags [S.], seq 3468957011, ack 2813245399, win 5840, options [mss 1460], length 0 12:29:24.106431 (authentic,confidential): SPI 0xc45bc3ea: IP 10.45.69.151.60847 > 172.16.61.5.5402: Flags [s], seq 1967001799, win 65535, options [mss 1460], length 0 12:29:24.106759 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60847: Flags [S.], seq 3478870357, ack 1967001800, win 5840, options [mss 1460], length 0 12:29:24.188918 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60845: Flags [S.], seq 3462681080, ack 2062812969, win 5840, options [mss 1460], length 0 12:29:24.788650 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60838: Flags [S.], seq 3432396299, ack 2638216950, win 5840, options [mss 1460], length 0 12:29:26.187985 (authentic,confidential): SPI 0xe4d9e8a3: IP 172.16.61.5.5402 > 10.45.69.151.60843: Flags [S.], seq 3456757893, ack 1621331004, win 5840, options [mss 1460], length 0 ^C 14 packets captured 115238 packets received by filter 0 packets dropped by kernel As you can see, the outgoing packets (from 172.16.61.5 to 10.45.69.151) use the SPI e4d9e8a3, which actually is from the SA for 172.16.60.24/32 <> 192.168.180.161\. As such, the packets never arrive at the host they are meant for. Does anyone knows what might be going on here? [/s][/s] -
Also getting messages like this in the ipsec log:
[2.2-RELEASE][admin@host]/root: tail /var/log/ipsec.log Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI 76734d7b: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI c0c56638: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI a0051ff3: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI c090e773: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI 3161f151: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI c9dfdbcd: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI b3d4b923: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI c62982f6: No such file or directory (2) Mar 13 18:03:45 tlbe-dtv-fw-1 charon: 13[KNL] unable to query SAD entry with SPI 22961c61: No such file or directory (2) -
Any luck with this?
-
Give a 2.2.3 snapshot a try.
https://snapshots.pfsense.org/ -
I believe these circumstances were largely resolved in 2.2.2, though the reqid bug in strongswan 5.3.0 could cause other issues there. 2.2.3 is definitely what you'll want to try if you're hitting this circumstance. Please let us know your results in testing ASAP, as we're nearing release.
-
I can't update to the snapshot, it's a production device. Sorry.
-
I am running into this exact same problem. I am running 2.2.5 AMD64 (IKEv1) and my packets are being sent with the wrong SPI.
I have a Site to Site tunnel with 2 subnets.
My packets are leaving pfsense with the wrong SPI, They have the SPI of my other subnet.
I have tried knocking the tunnel down and up, and doesn't seem to help. I have not restarted ipsec due to other tunnels working fine.
-
I found that whatever p2 subnet comes up first, is the one that it works, and pfsense uses that SPI for all traffic to the remote subnet.
The other end is a Cisco ASA 5505 v8.2(5)59. I can see traffic leaving with the correct SPI on the ASA side.
-
This is exactly what I'm seeing in 2.3.2. Did you solve it?
-
Probably an issue with the ASA. Try enabling split connections in the Phase 1.
-
That's exactly what it was. ASA does not support sending multiple SAs in the same TS payload.
