Strange behavior with IPsec tunnel and ESP packets getting blocked

thespirit

Hello all, this is my first post here, be gentle with me :)

We do have a strange problem with a pfsense IPsec site to site VPN. The configuration for the IPsec is fine and the tunnel is etablishing without problems for both phases. I checked that several times.

But after sometime of inactivity of the tunnel the remote peer cannot reach the VPN tunnel anymore. This is not true for the local network of the pfsense, which can send pings without problems. But it seems the remote peer is doing his job and using ESP to encapsulate the VPN traffic. But on the pfsense side we can see that the ESP packets get blocked on the WAN Interface with the "deny all" rule.

This will change as soon as I start a ping from the pfsense local network to the remote peer network. After that the ESP packets get not blocked anymore and routet within the IPsec tunnel (or interface) and the remote peer is getting successfull pings.

Can someone explain why this happens?
I also did some packet capturing and the ESP SPIs are fine and correct, so the pfsense IPsec rules should pick up the ESP packets but somehow its not doing that and instead blocking them.

pfsense is configured as responder with following settings:
Chils SA start action: None (Responder Only)
Child SA stop action: Close Connection and clear SA

remote peer is doing the initiation to the pfsense.

I don't have much experience with pfsense, but really can't explain why it is blocking the ESP packets, even if the SPIs are fine and is should get auto picked by the IPsec ruleset.

thespirit

Update to this problem. I could not ping from the remote peer to the local peer again. This time I just disabled (for testing) the "block all" rule and the remote peer was able to ping again.

Interestingly, after I enabled the "block all" rule again, the remote peer was still able to ping.
I really don't know why this happens, but I will manually add a rule for the ESP protocol and see if this helps.

Anyone an idea why this could happen? IPsec should have hidden rules created for that, according to the pfsense documentation.

femtosize

I think I'm seeing very similar things.

https://forum.netgate.com/post/1230492

My theory is that the manual block all rule is being hit before the hidden IPsec rules.
What I don't know is if that is intended behaviour or not.

thespirit

I just saw your post before. But as far as I can say its not breaking the rekeying or VPN in general for me. VPNs are etablished and active for both sides.
And I always can ping from the local network (pfsense fw) without problems, which than allows the remote network to answer again. Means there is no ESP blocking anymore.
Maybe the auto rules are the problem here, but I can't tell why.
I thought to enable the Disable all auto-added VPN (see link below) and just go with my own rules, but for now I will first monitor further and wait if someone here can explain that.

(https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/firewall-rules.html#ipsec-fw-outer)

femtosize

@thespirit I think the difference will be to do with traffic patterns. In my case it is the IKE which ends up getting blocked but in your case it is the ESP.
I'm sure this used to work fine so at some point the IPsec rules must have started being overridden by a block all rule.
The question is what is the correct behaviour. The old way where the IPsec rules won or the new way where the block all rule wins.

thespirit

@femtosize yes this could be.
For my understanding this should not happen, as the block rule comes at very last.
This may sounds stupid, but we will also try to restart the pfsense and see if this may helps.

What I really don't understand is, why it is working, once I have a ping from the local network to the remote peer network. Like somehow this enables the auto created rules for IPsec to get working again or getting "enabled" or what ever...