Mobile IPsec rules don't get added with reply-to, so it only works by default on the WAN where your default route resides. If you manually add UDP ports 500 and 4500 rule(s) on the other WAN, it'll add the reply-to, which will do the return routing correctly.

Could you get me into the system, or send me a backup of your config? Seems like your config didn't upgrade to add the uniqid tags on the P2s and I'd like to see why.

The other side should show something more useful in that case as to why it isn't responding. Or if it shows nothing, you'll know the traffic isn't reaching it. The fact that it's switching to NAT-T (port 4500) is usually indicative of a config problem with site to site VPNs, since neither end is using NAT generally. Though if one of the endpoints is NATed, then it's probably not replying because you're not forwarding UDP 4500 through the NAT.

I emailed Ruddimaster but wanted to post here as well for others. If you're having rekeying issues, especially with multiple P2s, applying this change and rebooting may fix. https://github.com/pfsense/pfsense/commit/afd0c1f2c9c46eaa8e496e98bea8a8e0887d504f

I was having trouble connecting with the Shrewsoft Windows client. I'm going to assume something else is wrong with the configuration and try again later. Thanks for the response!

You might consider posting your issue here: https://forum.pfsense.org/index.php?topic=83321.0

Hm, shouldn't be related with IKEv2, but do you have the Unity plugin enabled? https://redmine.pfsense.org/issues/4178 Only thing I can think of with a Cisco that would end up changing the selectors, though that symptom is completely different. What does your /var/etc/ipsec/ipsec.conf contain, and "ipsec statusall" show?

In the interests of making myself look silly and in case anyone experiences a similar issue: I went back over my IPSEC site 2 site configurations and noticed a subnet conflict mean't response traffic would've been routed down the wrong tunnel. One site to site p2 entry had qn erroneous 10.1.1.0/14 subnet which conflicts with 10.3.1.0/24! This explains the absence of response packets at the roadwarrior clients. Lessons learned: I hadn't posted enough details for anyone to be able to identify this issue. Post all IPSEC configuration, even components that are seemingly working. Check, re-check and then re-check all IPSEC configuration. I had previously discounted my site 2 site tunnels as potentially causing the issue. One change at a time, and make sure testing encompasses a client disconnect/connect before checking client traffic. Check the IPSEC SPD status tab once a roadwarrior client connects. It highlighted the issue for me and also enabled me to check SPIs on roadwarrior client traffic were as expected.

Phase 2 entries are still necessary, there is no "routing" with tunnel mode IPsec.

Thank you for your reply. It will be supported in the near future? Is it in the roadmap? Thank you. Best,

I have now solved this problem, detail can be found in the following post: https://forum.pfsense.org/index.php?topic=93065.0

transfering a 1GB zip file via Windows drag and drop.

I can't find any rules that could filter traffic based on OS. If we would have such a rule, where would I be able to find it? I have been looking around for an answer, and what I have repeatedly read is that this might be caused by split tunneling being disabled. I can't find any setting like that either.

@doktornotor: I can give it one final try on 2.2.2, after that, the entire IPsec things goes out of the door forever. Waste of time. Same problem in 2.2.2. You do not need to test it….  :-[ Congratulation you are in the fortunate position to switch to OpenVPN. I am not able to swith to native ssl, because I have a lot of foreign FW on the other side (ASA, Sophos, Juniper, ...). Unstable VPN-Tunnel --awkward situation for me---. I am really disappointed.

Edit the config manually and on <pool_netbits>add an IPv6 subnet and see if it fixes it?</pool_netbits>

@thiagomespb: I have enclosed tunnel and running perfect ipsec in two pfSense 2.2.2, however the website link B is dynamic .. did some testing .. if he falls .. the vpn not back, I have to go in and take a ipsec reload .. There is like leaving it automatically? Maybe you can try IKEv2 ? IKEv2 has been improved so that it is able to detect whether the tunnel is still alive or not. This is commonly referred to as a “liveness” check. If the liveness check fails, caused by the tunnel breaking down, IKEv2 is then able to re-establish the connection automatically. IKEv1 does not have this ability and would just assume that the connection is always up thus having quite an impact on reliability. There are several workarounds for IKEv1, but these are not standardized. http://www.differencebetween.net/technology/protocols-formats/difference-between-ikev1-and-ikev2/

@LakelandTech: We used to have our PFsense and Shrew clients setup exactly as PFsense instructions for roadwarriors. Could you point me to which instructions specifically?

Do you have any hw acceleration active on your systems or this is just from plain software crypto ipsec?

The only way at the moment I could connect in VPN to our CLOUD with iPad, was to install sonicwall VPN client, then connect to our own firewall through SSL to be redirected to our CLOUD network, which is not the best way to us.  ::)