Hi guys, Thank you for the provided information. As I have had a very busy week with training and courses I was not able to do some in depth tests yet. I did some quick and dirty testing with the information in these last 2 posts provided by you. I've tried various settings and combinations but all seem to fail. I think the problem is somewhere in the Apple Configurator profile, as everything is working very well on my W10 machine. I have also tried on a Macbook but was also unable to connect. I will provide a more detailed log later when I have some more time at home. Only thing what seems to be different in my setup is that I'm not using a self-signed certificate from a pfSense CA. There I was thinking it was not necesarry to add this certificate into the Apple Configurator profile. I'm using a Let's Encrypt wildcard certificate on my setup -> ACME installation in pfSense with auto-renewal, etc.. So I was thinking, like on my W10 it should work out of the box. However I did some quick tests with the settings provided by you guys (Machine Authentication, Server Certificate Issues Common Name, Server Certificate Common Name, etc..) but all with the same result. Anyway I justed wanted to let you know I'm not inactive but currently have no time to perform further troubleshooting. I will update this topic further this weekend with more screenshots and error logs. Thanks!

If both sides support VTI I would suggest that over GRE. https://www.youtube.com/watch?v=AKMZ9rNQx7Y

@harow Thanks for your suggestions on this. The problem hasn't occurred in the past two weeks, after I changed the P1 configuration from Initiator or Responder to Respnder Only.

As far as I know MSS Clamping is a workaround to avoid MTU discovery problems. I assumed that you have some filtering in the source-destination path (ICMP was my first thought) that prevent MTU discovery. Since throughtput was assymetric, I expected it to be fairly easy to find what was different and causing the issue at one end.

thanks for the update and great looking script! :) I had disabled PFS on both sides and had the VPN running ok but it appeared to stop passing traffic when the P2 timeout expired after 3600 seconds. By adding the rekey @ 540 seconds before expiry I 'think' its now stable. I run approx 25 VPN tunnels from two sites to remote sites and Ive replaced a remote pfsense box with a USG device at one remote site. From one main site ive had 100% uptime 19 hours to the USG Strangely the other main has had drops during the same period - 5,56,45 minutes breaks same IPSEC configuration (all other IPSECs from that site were ok) Both main sites pfsense 2.4.3

@derelict from the firewall fortigate in the capture I see the traffic coming out, but this does not reach the pfsense making the capture by ipsec Origin -> fortigate 192.168.0.0/24 destination -> pfsense 172.16.100.0/27 Something additional currently from that fortigate I have another vpn with another pfsense and it is established without problems these two vpn have the same configuration parameters. [image: 1550595465531-f8e30d6a-fb99-42f3-a31e-466357195f26-image-resized.png]

As long as it's IKEv2 it should be able to carry mixed traffic in the phase 2 / child SA.

I think the way to go is : Created routed IPSec with VTI Implemented some kind of dynamic routing, with BGP or OSPF, assigning different metrics to your path. Videos on theses subjects https://www.youtube.com/watch?v=AKMZ9rNQx7Y https://www.youtube.com/watch?v=4IlKcB17rWk

So for people who are facing the same issues. You need both a route on the pfsense (you must be able to see it with netstat -rn) And then, according to your firewall policy rules : if you use the default gateway (*) in your rules : OK if you use a specific gateway or a gateway group : assign a new rule throught the ipsec gateway I think the documentation should mentionned it. I'm not a native english speaker and after reading the doc, I thought, either static routes OR policy rules should work. But it's not an OR, it's an AND :) Regards

I have to admit, when I saw your post I thought that having a different number of Phase 2's on both sides would never work! However, it worked perfectly! I can now reach the other side from both my LAN subnet and my OpenVPN subnet. I cannot thank you enough, it was stupid of me trying to crack this one up for so long (weeks literally) when it was so fast to get awesome help here. Hope you have a perfect weekend. Thank you so much for giving me your time and even by trying the setup on your LAB. Regards, John

No. You need to use a site-to-site to route tunnel networks like you are trying to do. Mobile IPsec assigns one and only one address to a connecting client. It doesn't "route" subnets like a site-to-site tunnel. You need to work around dynamic IP addresses with something like dynamic DNS for each endpoint. Nothing you come up with there will be perfect. Especially if the addresses simply change abruptly. Set each side to update a Dynamic DNS entry pointing to their actual, routable, outside WAN address. Tell each side to connect to the FQDN of the DynDNS entry on the other side. Set each side to use their own FQDN as the IKE identifier locally, and the other side's FQDN as the remote identifier.

Depends on the hardware. At least dozens. Possibly hundreds. There is no set limit but there are practical limits that vary by installation (like hardware and webgui performance for managing them all.)

Solved it by adding a P2 for the LAN and blocking all traffic except 1812/tcp from the AP.

No. The tunnel interface addresses are specified in the Phase 2 configuration.

@roveer said in Mobile IPSec working but was expecting _route all_ and that's not happening: So you actually took the time to reply to my post and to say. You are stupid and you don't read. That's how it came off. Not very helpful. Not all of us are perfect. You need to be aware of your failures so you can avoid them in the future.

Thank you, for your feedback! I will give it a try. Sebastian