@viragomann Thank you for your response — I really appreciate you taking the time to help. However, I’ve already tested the exact scenario you're suggesting. Unfortunately, it didn’t work in my case. What I’m specifically looking for is feedback from someone who has successfully implemented Source NAT in a setup that matches my parameters, particularly: Site-A to Central-PF using IKEv2 Central-PF to Site-B using IKEv1 NAT at Central-PF, where Site-A is NATed to Central’s LAN IP before forwarding to Site-B I’m aware that when both IPsec tunnels use IKEv2, NAT works fine and there’s no need to configure BINAT or additional Phase 2 entries. However, in my situation — with mixed IKE versions — the NAT rule doesn’t appear to work as expected. If anyone has resolved this exact case or has real-world experience with this specific type of mixed IKE/IPsec/NAT scenario, I would greatly appreciate your insights. Thanks again!

@dcugy I would update to the latest CE 2.8.0-RELEASE and report it when it happens again.

wanted to see if i could try pfsense+ edition which used to be free but for some reason i can't seem to find that key, isn't it free for home users anymore?

For some reason this is not working under Windows 11 24H2. I assume it has something to do with local access rights since I am also not able to copy the file via explorer directly from the network share to C:\ProgramData\Microsoft\Network\Connections\Pbk (as local admin without elevated rights). When I first copy the file to Downloads, then I am able to copy it in a second step to C:\ProgramData\Microsoft\Network\Connections\Pbk. Any ideas? Indiana Horschd

@tinfoilmatt thanks. The iperf3 tests are done on hosts, not on the firewalls directly. Interestingly, I've since also set up a WireGuard VPN and that seems to work a little better than IPsec, but still 20-30% slower with large file transfers over FTP than going over the WAN. Following the guide on Netgate's website for WireGuard, I noticed that they clamp down the packet size by adjusting the MTU rather than the MSS, I don't know if there's a reason for doing it like that. But as I'm seeing the WireGuard performance still a bit off, maybe it's not just an IPsec thing? I did wonder if the CPU was the bottleneck, but they never go above 20% or so usage so I doubt it's the processor that's the bottleneck.

OK, this has been working correctly for a couple months, but a few days ago the interface "lost" the IP address. The router hasn't restarted nor I can find anything in the logs. Had to reassing an IP address and it just continued to work. I will try to dig deeper in the gateway address handling to see if I find the bug.

I have run into the same issue a while ago. As others have mentioned, it is due to Windows using DH group 2 (1024 bit) at re-key time, even if it the P1 and P2 are configured with a stronger DH group. Changing the re-key interval to something like 9 hours is the easiest way to minimize disruption. Other options are to create the client connections using PowerShell to specify a higher DH group, or use DH group 2 on the server. https://learn.microsoft.com/en-us/powershell/module/vpnclient/set-vpnconnectionipsecconfiguration?view=windowsserver2025-ps

@TitaniumCoder477 Send a print of Status / IPsec / SADs and SPDs while the GEN_VLAN gateway is unreachable.

Okay, after a long troubleshooting session. Problem is solved. For reference, I needed to recreate the firewall rules on both sites for ipsec, reload filters and reset states. I suspect it was a weird gimmick messing up the filters.

@viragomann @tinfoilmatt Based on your feedback I read up on asymmetric routing and ended up skipping pfSense for this setup altogether I always try to standardize on products but here it just lead to a level of network knowledge I do not fully understand. I configured a basic IKEv1 tunnel in the edge gateway, added necessary firewall rules and everything worked as intended. A sidenote is that IKEv2 did not work well in VMware NSX-V with the P2's being disconnected after 3600 seconds and not being able to reconnect without tearing down the P1 manually as well. [image: 1745913956839-ef365c84-1553-4c71-8c60-fbb1827af9a7-image.png] Thanks everyone for your input!

@stan-fergusonsmith Does your application really use a static source port?? That's very unusual. Most application use a random source port. So you probably have to set the source port to 'any' in the port forwarding and firewall rule.

I know this is an old topic but I got here from searching the error message. In our case the person adding the VPN didn't use the .ps1 file from pfSense to do it, and Windows 11 24H2 still apparently uses weak algos by default.

@michmoor I would love to give your reply a thumbs up, but apparently you have to have 5 something, and no clue on how to get that. Anyway, I'm going to look at wireguard; however, i upped my p1 timeout, rekey, and expiry times to 7 days then 10 under for rekey and 2 under for expiry and i've gone ahead and upped the p2 to 1 day and rekey at 5 minutes under. That was at 13:44 and we are now at 16:17 and we haven't had a drop yet.