It's not suitable for me, because IPSEC failover using Dynamic DNS and multi WAN doesn't work properly (with WAN failure it need some time to resolve new IP, and when WAN is UP DynDNS is not refresh so fast, but IPSec is using wrong WAN gateway and didn't connect till DynDNS new IP refresh). I want to make load balancing with IPSec VTI gateways (without connection drops) on pfSense side, so - both connections must be UP all time. and when one connection is fails - another stay UP without any connection drops for tunneled networks. But, as i see, it isn't standard situation for pfSense IPSec - when 1 WAN Server is using for 2 WAN's Servers.

@hdservices said in KeyID tag issue since 2.4.5: May 6 07:58:47 charon 08[CFG] <290> candidate "bypasslan", match: 1/1/24 (me/other/ike) May 6 07:58:47 charon 08[CFG] <290> looking for pre-shared key peer configs matching x.x.x.x...x.x.x.x[192.168.1.60] May 6 07:58:47 charon 08[ENC] <290> parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ] May 6 07:58:47 charon 08[NET] <290> received packet: from x.x.x.x[4500] to x.x.x.x[4500] (108 bytes) May 6 07:58:47 charon 08[NET] <290> sending packet: from x.x.x.x[500] to x.x.x.x[500] (396 bytes) May 6 07:58:47 charon 08[ENC] <290> generating ID_PROT response 0 [ KE No NAT-D NAT-D ] May 6 07:58:47 charon 08[CFG] <290> candidate "con1000", match: 1/1/3100 (me/other/ike) May 6 07:58:47 charon 08[CFG] <290> candidate "bypasslan", match: 1/1/24 (me/other/ike) It's selecting bypasslan which means the P1 info didn't match. Either you didn't match up the ID (Looks like the remote is sending 192.168.1.60 as its ID) or the Pre-Shared key for 192.168.1.60 could not be found.

Phase 1: IKEv1 IPv4 PSK Aggressiv Distinguished name Distinguished name PSK Generate by pfSense AES 256 SHA512 DH2 DPD on Phase 2: IPv4 NAT None ESP AES 236 SHA1 PFS Key Group 2 Lifetime 3600 However, a new Netgate has been ordered and replace the Fritz shortly.

Great that it is working now as it should be. And my respect that you stayed on this till you solved it and posted the solution here.

here also, earlier here on the forum, @groupers made recommendations, you can also stick to them [https://forum.netgate.com/topic/150670/safe-ikev2-configuration-for-pfsense-and-windows-10-and-macos](link url) although they contradict what I wrote above, (deleting the registry key, and setting up the algorithms through the powershell) the essence is the same = setting the same parameters both on the pfsense and on Windows

pfSense doesn't support that role currently for a couple reasons: It does not support acting as an EAP client (Or any remote access style IPsec client) It does not support accepting parameters pushed by the IPsec server (e.g. dynamic addressing, DNS, etc) And a few other related reasons but they boil down to the two above.

Thanks, that's what I thought. Both have distinct peers. They are reporting they are receiving IKEv1 packets but the config is most definitely set for IKEv2.

@helviojr said in IKEv2 VPN for Windows 10 and OSX - HOW-TO!: @josey: I guess i have to add default route for servers subnet? but what is my gw then, because there is no IPV4 address of IKEv2 under connection details. I didn't test IKEv2 yet (still on L2TP with IKEv1), but it seem you can create route using device, instead of gateway IP: use ipconfig to get the name of each device (you probably can get those form GUI also); use route print to get the number of each interface, and get the one of your VPN device (the table at the begining of "route print" command output); create the route using "IF" option instead of the gateway address: route ADD 10.10.10.0 MASK 255.255.255.0 IF 10 -p (this would create a route to subnet 10.10.10.0/24 through interface number 10) Sometimes I prefer the Powershell command: Add-VpnConnectionRoute -ConnectionName "[vpn_connection_name]" -DestinationPrefix [network]/[Prefix] so for example it becomes: Add-VpnConnectionRoute -ConnectionName "[vpn_connection_name]" -DestinationPrefix 10.10.10.0/24 I use this because connection name is simple to recognize even for people with no technical skills.

BTW: IPsec works perfectly. You can see it was connected for a while when l2tp is down.

Hi jimp Thanks for your help. I agree that they seem to be being difficult but I'm not sure I have the time or indeed the knowledge to argue well enough. I have started looking down the route you suggested and have managed to create a user with their own IP. This is a remote site and i need someone to go down and physically move the equipment over to ETH8 so i can test. Will let you know how i get on. Once again - thank you

Ok, I just changed the DynDNS host name for my router so that only the A record is give back by DNS and no longer the AAAA record. And it seems that the connection is now fast again... Thanks for pointing me to the right direction. I guess that my mobile provider now give me a IPv6 address as well, so that the iPhone does try that first before falling back to the IPv4 address.

@marcquark said in 2.4.5 <-> 2.4.4-p3 IPsec tunnel stops passing traffic after ~48 hours: Just to clarify, are you seeing the tunnels as up (both P1 and P2), but no traffic passing from one side to the other? I'm sorry I'm not sure it is the same issue. We started the IPSec Tunnel and everything was fine, until around 48 hours afterwards, at which point traffic seems to stop flowing over the tunnel, save for the DPD requests and responses suggesting the tunnel itself is fine. I think we have resolved that problem too. Again, we have no idea why rekeying was disabled on the P1s, but having enabled it the tunnels have been working faultlessly for just over 10 days.

<30>May 3 13:05:41 charon: 11[KNL] <con1000|3> querying policy 0.0.0.0/0|/0 === 0.0.0.0/0|/0 in failed, not found Messages like this repeated over and over at alarming frequency. They still show up when the tunnels are working well, but at much lower frequency. [image: preview] Count dropped off a cliff when I killed the charon process.