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.

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.

My problem was resolved once I have change IP from dynamic to static. DHCP was adding some records to arp table which were confusing pfSense.

There isn't a way to do that with IPsec+DHCP. You could setup a RADIUS-based auth method for IPsec and then assign addresses through RADIUS (NPS) on Windows. But not DHCP.

The rules were automatic, the issue was the remote and local identifiers needed to be present. Any / Any did'nt cut it. All sorted although I did'nt find that answered anywhere here.

Please ignore, it was a configuration error during IPsec setup. Incorrect network for remote.

@jimp /64 in "address" is obvious. No... Will try.

@sblinov said in IPSec/IKEV2 error "trap not found, unable to acquire reqid": I have updated pfSense to 2.5 dev release and I found some connection issues, can't connect to Ikev2 IPSec mobile users. They are use PSK authentication. I tried different settings and it was ni successful for me. @geovaneg @jimp please double check it Start your own thread for that, it isn't related to the topic of this thread.