Sorry to dig up an old post, but I was wondering if you ever found a solution? I have have an ongoing problem very similar to yours and like you discovered, it only seems to affect my systems that are running 2.4.2 or later. Link to previously created thread. https://forum.pfsense.org/index.php?topic=143728.0

It seems to be a regular win10 IPv6 VPN client problem. Maybe it should be solved by using link-local addresses on IPsec interface. For now I have solved the problem by creating a power shell script to create a windows VPN connection definition. The script adds route ::/0->:: Add-VpnConnectionRoute -ConnectionName $connection_name -DestinationPrefix ::/1 Add-VpnConnectionRoute -ConnectionName $connection_name -DestinationPrefix 8000::/1 The Add-VpnConnectionRoute cmdlet does not allow to manipulate with ::/0 , this is why there are two routes, for ::/1 and for 8000::/1 And how are you, who already uses IPsec on IPv6, working with client routes? Are they automatically created? Do you use link-local addresses on IPsec interface?

Its ok I figured it out…didn't have the correct rule on the IPSec Rules for the firewall...all good now thanks

Double check that you are using IKEv2 on both ends. This looks like IKEv1 with UDP Port 500 : Mar 5 16:36:52 charon 16[NET] <1> sending packet: from 78.94.x.x[500] to 80.187.96.197[500] (337 bytes)

We have this setup for small remote officers (about 10 to 15 users at each office) You just want to make a IPSEC tunnel from A to B, A to C, A to D and so on. I would test it with: IKEv1 Mutual PSK and Pre-Shared Key AES 128 bits SHA1 - DH 2 AES 128 bits SHA1 PFS key 2

@TMSUnited: I have a Draytek 2860 connected to pfsense on 1and1 cloud.  I can establish a connection and the network performs as expected.  However, even though I have set the time out in Phase 1 & 2 to 86400 the connection drops after 59 minutes. I also tried setting up a ping xxx…. -t from both ends but this didn't keep the connection alive.  the Draytek is set to keep alive so it looks like Phase 2 is forcing this to drop after an hour.  The Draytek is set up to Dial in only. pfsesne is 2.4.2 I see quite a few issues with IPSEC so wondering if this is a psfense bug.  I used a 1.x version before and the connection was faultless for years. Thanks Do you have a "Automatically ping host" setup on phase 2?

I'm very new to this but I had the same issues connecting my Draytek 2860. With 2.4.2 I tried with two colleagues to connect with various combinations and in the end it only seemed to work on IKV2 with 3DES on G2 for phase 1 and 3DES_MD5 for phase 2.  In the end Draytek support solved the issue.  You may find it is different for ZyXel.

@ikkuranus: Are you aware that 192.0.0.1-192.167.255.255 are public addresses and shouldn't be used for private use unless assigned to you by your ISP? 192.1.x.x and 192.2.x.x fall into that range. Yes I am aware ;) Its all working now with the setup we need. Thank You

From your "diagram", they are the ones who have to NAT. What is the IPsec access list on the ASA side? What is the phase 2 defined on your side (including any NAT if present there) ?

SOLVED I forgot to add firewall rules firewall->rules->ipsec: add rule to allow traff from ASA-side to LAN

I have logged into the router at the other end, and it has almost the same messages (over & over) in the IPSEC log: Mar 6 16:30:12 charon 05[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:12 charon 05[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:12 charon 06[CFG] ignoring acquire, connection attempt pending Mar 6 16:30:12 charon 06[CFG] ignoring acquire, connection attempt pending Mar 6 16:30:14 charon 06[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:14 charon 06[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:14 charon 13[CFG] ignoring acquire, connection attempt pending Mar 6 16:30:14 charon 13[CFG] ignoring acquire, connection attempt pending Mar 6 16:30:17 charon 06[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:17 charon 06[KNL] creating acquire job for policy 223.252.22.77/32|/0 === 203.49.236.246/32|/0 with reqid {3} Mar 6 16:30:17 charon 05[CFG] ignoring acquire, connection attempt pending Mar 6 16:30:17 charon 05[CFG] ignoring acquire, connection attempt pending Maybe I need to change the level of logging? Or need to look at a different log? Also in the IPSEC Status screen I can see the connecting trying twice in parallel (see attached image) [image: IPSEC_Status.JPG] [image: IPSEC_Status.JPG_thumb]

Thanks for the quick reply! I have tried wide open (ip any any) rules on both the ipsec interface and the LAN interface, and tested initiating connections in both directions.  It would always allow in to enc0 but "default deny out" of enc0.  I will setup to test again and get some state info and captures on the interfaces and post the results here.  It may take a couple days to get time to do so.

OpenVPN will be a lot more flexible for that.

That's because you cannot policy route IPsec like you can OpenVPN. You might be able to use a phase 2 of 10.47.5.0/24 <-> 0.0.0.0/0 with the reciprocal on the other side, but OpenVPN is a lot more flexible in this regard.

I think we want to do the same thing ish https://forum.pfsense.org/index.php?topic=144475.0

Windows clients use 3DES for the encryption, use 3DES in the phase 1 of the IPSec tunnel instead of AES. Source: https://support.microsoft.com/en-ca/help/325158/default-encryption-settings-for-the-microsoft-l2tp-ipsec-virtual-priva

Thanks Buddy