Bug #15155
closed
Mobile IPsec traffic stops working after approximately 55 minutes
0%
Description
Windows 10 clients using the builtin IPsec client connecting to pfSense 23.05.1
Most of the time everything works great but we've had several incidents where the mobile IPsec does a rekey/reauth around 55 minutes after the connection was initially established and then the client loses access to resources through the VPN. Users must disconnect and reconnect to the VPN in order for the VPN to work again.
Rekey and Reauth are set to 0 (disabled) in pfSense.
A packet capture of the pfSense IPsec interface shows that packets are being sent/received to/from the client, but Wireshark on the client shows the client is sending packets but is not receiving any packets.
Packet captures of the pfSense WAN interface and the client both show ESP packets being sent and received.
It appears that the P1 is working correctly but the P2s are no longer being sent from pfSense to the client.
There is a floating firewall rule to block traffic destined for the mobile IPsec subnet from establishing states on the WAN interfaces. I confirmed there were no states present on the WAN interface that were destined for the mobile IPsec subnet.
When the P2 is manually disconnected on the pfSense side, it reestablishes correctly but the client still can't access VPN resources.
You can see this happening in the attached log at these times:
1/10/2024 12:55
1/10/2024 13:47
1/10/2024 14:43
The entries at 15:23 are from me manually disabling the P2 on the pfSense side.
When the issue begins to occur, all clients are affected.
Restarting the IPsec service fixes the issue.
Files
Updated by Brad Smith 4 months ago
I've seen this before. It's an issue with the Windows 10/11 VPN client. I can't remember what the fix was but it's something stupid like Windows 10/11 re-keys the Phase 2 with PFS even when PFS isn't enabled or something like that. I think this would be better on the netgate forum as I don't believe it's a bug or pfsense fault. I'm happy to share my config details that work on the forum.
Updated by Jim Pingle 4 months ago
- Status changed from New to Not a Bug
This is almost certainly a config issue. Also possible that something changed between 23.05.1 and 23.09.1 so you should upgrade and test again, as problem reports against older releases are not valid unless they can be reproduced on the latest release or dev snapshots.
Updated by Andrew Almond 4 months ago
In the most recent case, it was working perfectly for 6 months since the last time this occurred, and then yesterday it suddenly affected everyone, including my machine, which isn't part of their network/domain.
If it was a Windows issue, then restarting the IPsec service shouldn't suddenly fix it for all workstations, correct?
Is it possible that Strongswan goes into an "altered" state after something like a long period of time, cumulative number of IPsec sessions, a certain traffic pattern, etc?