Traffic inexplicably not going through IPSEC despite (in theory) matching SPs
I am running a pfSense 2.4.0 twin installation with CARP between the two appliances.
I have been able to successfully establish a transport mode IPSEC connection, using a CARP VIP, between the pfSense installation and an external Linux machine, both using strongSwan to handle the negotiation.
On top of the IPSEC connection I am running a GRE tunnel between the two endpoints.
One problem I've encountered is that I had to forcefully disable stateful inspection on the packets going through the gre0 interface, otherwise after a few tens of seconds packets started getting dropped by the default rules on pfSense, stalling and terminating connections.
That behaviour didn't arise if the GRE tunnel was established without an IPSEC layer underneath.
Something at least related to this issue here https://redmine.pfsense.org/issues/4479 I think.
Anyway that is not what's still bugging me.
Something else is quite strange.
Let's say that my CARP VIP, the pfSense endpoint of the transport mode IPSEC "tunnel", is 220.127.116.11, and the other endpoint is 18.104.22.168 .
So basically on my pfSense I have a security policy directing the traffic from 22.214.171.124 to 126.96.36.199 through IPSEC (the actual traffic is UDP-encapsulated, btw).
But if I try and ping 188.8.131.52 from a client behind my pfSense installation (ICMP traffic this going through outbound NAT and exiting the firewall having 184.108.40.206 as source address), this traffic does not go through IPSEC, as a traffic capture on the outside interface shows me.
The machine on the other side tries to send answer packets through IPSEC instead (I think).
So basically, ICMP traffic for 220.127.116.11 going through outbound NAT translating the source address to 18.104.22.168 doesn't go through IPSEC encapsulation even though, from what I understand, it should match the SP with those exact source and destination addresses.
I've read somewhere about a FreeBSD and pfSense problem related to performing NAT before IPSEC encapsulation but I am not sure whether it's relevant to my case or if it's out-of-date information.
I've tried to understand/debug the flow but I haven't found anything to help me sort out this situation.