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.

alt text

Count dropped off a cliff when I killed the charon process.

So i did eventually figure this out in case anyone is interested. This was due to the configuration of the VPN server on the PFSense and the configuration of the network security gateway in azure. The client uses VPN servers for different groups so rather than just give everyone access to the LAN, they specified subnets people have access to. I needed to update the allowed subnets on the PFSense to include the subnet for azure resources, and then azure needed to be updated to allow the VPN users from the PFSense.
Which totally makes sense when you see the symptoms. Should have thought of it a while ago.