Check your phase 1 and phase 2 lifetimes, sounds like there is a mismatch.

@David_W: As jimp has stated in the forums several times recently, IPsec using IKEv2 is probably a better option than L2TP/IPsec at this point. I have no problems using Windows 7 Professional clients with pfSense's IKEv2 support. Ok did that, and it worked ^^

i am doing it another way now, i am just using "mutual PSK" for authentication but i still cant get it to connect got screenshots incase it helps ipsec_site.zip

I believe it has to do with the nat rules in the asa you need to tell the asa that any traffic destined for the tunnel cannot go out the wan interface. I did it once don't remember the exact steps however.

Assuming that A, B, and C are all running pfSense it's relatively straightforward. Example LANs: Router A -> 10.10.0.0/24 Router B -> 10.20.0.0/24 Router C -> 10.30.0.0/24 Router A –--------- Phase 1 on A heading to B has two child Phase 2 1. 10.10.0.0/24 -> 10.20.0.0/24 2. 10.10.0.0/24 -> 10.30.0.0/24 Router B (B must know what to do with transiting traffic, this is probably what you're missing) Phase 1 on B heading to A has two child Phase 2 1. 10.20.0.0/24 -> 10.10.0.0/24 2. 10.30.0.0/24 -> 10.10.0.0/24 (C -> A Transit) Phase 1 on B heading to C has two child Phase 2 1. 10.20.0.0/24 -> 10.30.0.0/24 2. 10.10.0.0/24 -> 10.30.0.0/24 (A -> C Transit) Router C Phase 1 on C heading to B has two child Phase 2 1. 10.30.0.0/24 -> 10.20.0.0/24 2. 10.30.0.0/24 -> 10.10.0.0/24 Also make sure that under Firewall -> Rules -> IPSEC that you pass IPSEC traffic for anything (all asterisks in all columns) on all routers. After getting the tunnels up you can make finer grained rules if you want.

That's probably not what you want for a site to site connection. There are a variety of potential routing complications. The Draytek should support a proper site to site IPsec connection without L2TP's inherent complications, use that instead.

@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