@inexces: I have this problem after upgrading to 2.2.4 charon: 07[ENC] <con1|2>invalid HASH_V1 payload length, decryption failed? charon: 07[ENC] <con1|2>could not decrypt payloads charon: 07[IKE] <con1|2>message parsing failed</con1|2></con1|2></con1|2> Upgrade to latest 2.2.5 snapshot (or release if it's out by the time you see this), that's probably the same root cause as this (which is confirmed fixed by several people in 2.2.5).

Upgrade to latest 2.2.5 snapshot, that's probably the same root cause as this (which is confirmed fixed by several people in 2.2.5). @dcandea: Based on strongswan https://wiki.strongswan.org/issues/460 try with modeconfig=pull That has no relation in this case.

@djamp42: It's being worked currently. https://redmine.pfsense.org/issues/5149 There's an update on that ticket. Next snapshot run should resolve the serious leaks.

Little progress? I deleted and re-created the problem tunnel Gave it a new key and set it at main mode instead of aggressive. Lasted just over 24 hours before dropping. Other tunnels still remain stable. Does anyone have any ideas?

Thanks cmb, you were right. The Cyberguard is behind a Sitecom X4 N300 router. This home router has an "Ipsec pass through" option which sadly does not pass UDP 4500. Explictiy allowing it fixed the issue. Regards,   Corrado

Hi I managed to make it also work with Mutual RSA and Xauth. Strongswan has support for xauth-radius replace line $rightsourceip = "\trightsourceip = {$a_client['pool_address']}/{$a_client['pool_netbits']}\n"; with $rightsourceip = "\trightsourceip = %radius\n"; and $authentication .= "\n\trightauth2 = xauth-generic"; with $authentication .= "\n\trightauth2 = xauth-radius";

Read this and use the latest 2.2.5 snapshot. And stop necroposting to 2+ years old threads dealing with completely different pfSense versions.

It is working using IKE2. Thanks.

In cases when there is a subnet conflict on both sides with a VPN, both sides must perform NAT+IPsec, but this is different since it's the LAN on one side and WAN on the other. Unless S1 needs to talk to S3A you only need NAT on the S1 side. You don't need to setup port forwards and other things, just on that particular IPsec Phase 2 you need to setup a NAT subnet. S1 would NAT its 192.168.10.0/24 to, say, 10.10.1.0/24. On S1 in the IPsec Phase 2 settings for the tunnel to S3, just put that in the NAT/BINAT option. To reach 192.168.10.1 at S1, a client at S3 would instead contact 10.10.1.1 for example. Unless there is some other quirk I'm forgetting with the WAN side at S3 that should be OK

I have the same issue, rebooting once a day seems to be the only decent fix for now  :-\

I'm having similar issues. https://forum.pfsense.org/index.php?topic=100779.0 I've just updatet to the latest 2.2.5 as advised here. See if it helps. The loading of diag_ipsec.php still needs some time.

Seems to be linked to this problem https://forum.pfsense.org/index.php?topic=99604.0 I've updated to the latest 2.2.5 Version today. Report back how I goes UPDATE: Seems to have done the charm. Issue that I have left, is that the SAD tab is flooded with entries. Most of them coming from the same IP. Is there a way to manualy clear all of them?