Your mobile vpn needs another p2 so that the mobile IPSec knows about the remote network.  It does not get that from the point to point.

jvata, I spent countless hours trying to get this to work, the fix for this is here https://forum.pfsense.org/index.php?topic=105589.msg608136#msg608136.

No problem glad I could help. Just to confirm though you shouldn't actually need the static routes. Either AWS network should know how to get to the other side due to the phase 2 entries that you've created. The static routes can be removed in your instance.

This is totally what i needed. It works perfectly. :) Thanks for your reply jimp.

You can change this on the Phase 1 page.

Lots of problems with that cert for IKEv2… It's not marked a server cert Missing EKU for TLS Web Server Authentication and 1.3.6.1.5.5.8.2.2 IP address is not in the SAN list

@kapara: I have deployed at several locations the IPsec VPN using the Microsoft integrated with VPN using the Microsoft integrated with IKEv2.  So far it's his man pretty much flawless! […] IKEv2 on Mac also flawless! Any chance you could post detailed screenshots of how you set that up? I spent wasted 2 whole Saturdays fiddling trying to get it to work on MacOS X 10.11 as well as iPhone without much success. Wife was not happy.  :-\

Most people prefer security Which is what i prefer as well. I was not aware that Mutual RSA would be a less secure authentication method, compared to EAP-TLS. Guess i need todo some more research. You can open a new redmine entry (target = 2.3.1) and we can look into adding that for the next version. Great! I just did: https://redmine.pfsense.org/issues/6082 Thanks in advance!

Why? If it's for IKEv2, use EAP-RADIUS and setup a RADIUS server. It will undoubtedly be easier to import users into RADIUS than to have that many PSKs stored on the firewall.

Hi, when i start a ping, i can see the traffic on both sides with tcpdump. But in Status/IPsec the counter for established SA stay at 0 best regards Thomas

Ok. First things first the DrayTek call direction MUST be set 'Both'. No matter what I tried I could not get this to work with it being 'Dial-Out'. You will also need to set the 'Idle Timeout' to 0 which will keep the tunnel up indefinitely. As the call direction is set to both, make sure you fill in '3. Dial-In Settings' so the pfSense can renegotiate the tunnel where required. My phase 1 lifetime is set to 28800 seconds and my phase 2 lifetime is set to 3600 seconds. On the pfSense, make sure that 'Key Exchange version' is set to 'V1'. I found that leaving this to 'Auto' broke the tunnel as pfSense tried to reinitialize the tunnel using IKE V2 by default, and DrayTek only supports IKE V1. That's all I really needed to set of the pfSense side. Under 'Avdanced Options' I have left both 'Disable Rekey' and 'Responder Only' unchecked but have 'Dead Peer Detection' enabled. My phase 1 lifetime is set to 28800 seconds and my phase 2 lifetime is set to 3600 seconds. This setup does mean you need to bring the tunnel up manually, however if either side receives any traffic for the remote network either peer will be able to bring the tunnel up. Once the tunnel is up, it will remain stable regardless of wether or not any traffic passes through it. This should fix the issue and you should have a stable VPN tunnel, you can check this by looking at the 'UpTime' on the DrayTek under 'VPN and Remote Access' > 'Connection Management' > 'UpTime'. My tunnel has been up for over 48 hours now whereas previously I this was disconnecting constantly. If you're still struggling with this, if you are happy to provide me access to both a DrayTek and the pfSense, I am happy to take a look at this for you. Hope this helps!

I managed to fix this. The problem was I set 'Key Exchange version' to 'Auto' and it should have been to to V1. All showing as expected now.

Have you been able to connect to that mobile VPN with any other clients that aren't Windows Phone? Nothing in the logs you posted suggest that it's being rejected by the server, which means the client is rejecting something the server is sending. 9 times out of 10 that ends up being something that isn't right with the server certificate.

The original issue looks like it comes down to this: generating CREATE_CHILD_SA response 1 [ N(TS_UNACCEPT) ] TS_UNACCEPT is why the other end's rejecting it. Traffic selectors unacceptable. Mismatched local/remote in P2.

@froussy: Good day, I'm using my box with pfsense for 3 purpose.. 1. Internet Access 2. to replace the hub provided by my IPTV provider ( I did: https://forum.pfsense.org/index.php?topic=87738.0) 3. to connect to my work, to our Fortigate, using IPsec My work network have multiple sites connected to one main site (our head office). All those network are 192.168.2.x, 3.x, 4.x, to 12.x/24. It's all routed base with ospf My home network is on the 172.16.35.0/24 network, so I dont overlap. So. On my pfsense, I had created a tunnel to my work place. I had created the phase 1, then multiple phase 2 for all those other network. I also add in gateway, the IP of the local pfsense box (172.16.35.1), and add a route for each remote network. My IPTV work fine! and the internet too.. BUT… I'm able to ping/tracert and access a lot of devices on all those work network, and from work, I can access my home pc perfectly. From work:  I can connect to ALL of my work routers (192.168.2.1, 3.1....) even my home (pfsense) one 172.16.35.1 without any issue! From home.. there is where is issue seem to be.. :  I can reach many devices/server.. for, i can ping all of the remote routers (192.168.2.1, 3.1....). When I try to access them with a browser, I see (using firefox, or any other one) on the status bar "connecting to 192.168.2.1).. for a few minute.. then, cannot display the page.. I dont know where to look :( Thanks a lot Frank Hey, try this: https://forum.pfsense.org/index.php?topic=106654.0 Br, Greg

You can test in both ends if AES-NI is enabled by using openssl like in the following link. https://calomel.org/aesni_ssl_performance.html You also needs to enable AES-NI in pfsense in the system->advanced "cryptographic hardware acceleration" settings somewhere and reboot the unit. Maybe the hyper-v isn't passing the AES-NI feature to its host so you can also check that. We had some issues getting hyper-v to work with AES-NI both after some updates and random luck we got it working but i can't guide you on what we did :D. IKeV2 AES128-GCM or AES256-GCM for both P1 and P2 should be fine (until they mistakenly removes GCM option in P1 in pfsense 2.3 again :/ )

If you could post up your configs, it should make it a bit easier to troubleshoot. Cheers.