Once upon a time, Paul Wouters <[email protected]> said: > > >There are 2 subnets on my end and 4 on the remote, so there are 8 > >connections total. They'll connect okay, but traffic isn't passing on > >most of them. What's weird is that when I look at "ipsec trafficstatus" > >it looks like my test pings are going out the right connection, but the > >responses are coming back in a different one (associated with a > >different subnet on my end). > > There was a connection switching bug that could cause this when you had > mismatched subnets between the two endpoints. This was fixed in > libreswan 4.5. But a workaround is to ensure you _exactly_ match up > the subnets between the two endpoints.
I believe all the subnets match (the remote admin sent me screenshots of the pfSense config and they all look correct). > >/proc/net/xfrm_stat shows XfrmInTmplMismatch incrementing (which I don't > >find many Google references to, but would seem to match my thought that > >the remote site is sending packets on the "wrong" connection). If I run > >tcpdump on WAN interface, I see the ICMP echo replies from the remote, > >so it appears the packets are being received and decrypted (both sides > >are RFC1918 space so they're not coming across the Internet), but then > >dropped? It doesn't appear to be firewall related (the remote subnets > >are in the local firewalld "trust" zone, plus I turned on firewalld's > >log-denied and there weren't drops logged). > > another issue _could_ be that the remote end is actually NATing the ICMP > and the NATed source IP matches that different subnet? There's no NAT on either end for this either. -- Chris Adams <[email protected]> _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
