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.  ::)

@vibenation: @iced98lx: Joe-   This thread isn't suggesting that the cisco client won't work behind a pfSense firewall, it's suggesting the pfSense firewall can't be configured out of the box to accept connections IN from that client.  We're discussing if your wife's new employer was using pfSense as the tunnel endpoint, not if you were using it as a firewall from home. Apparently I need to go to the Zoolander reading school….Thank you for clearing that up for me.  I suppose thats what I get for trying to burn both ends of the candle at once! I will attempt the deployment this weekend when I can test it without impacting her normal work routine. Joe No worries, I don't expect you'll hit any snags connecting, I used cisco vpn software behind pfSense for a long time.

@jasonr: I had to chown -R root:wheel /etc/ in the GUI to get ssh and console to work.  Upgrade messed it all up. I found the source of that issue looking at covex's system. I just fixed that issue, or worked around it at least, by re-issuing the full update files again with "chown -R root:wheel *" of what's within them (when they were re-packed they lost that, which shouldn't matter, but mtree is failing after upgrade from any pre-FreeBSD 10.x base version). We're looking into a proper long-term fix now, but that shouldn't happen upon upgrade to 2.2.2 from 2.1x and earlier versions anymore.

I had this happen to me and started going nuts trying to track it down after my upgrade. When I deleted my phase 1 and 2 entries and rebuilt them using the exact same settings, my issue went away. (well, this particular issue anyway) I should have captured the config files associated with the GUI to compare.

@iorx: Hi! Digging around on one other issue and saw this. Maybe this be of help with your issue. My LAN routing to the other side of the tunnel was OK but I couldn't get pfsense to reach it (resulting in not DNS Resolver working among o.t.) This solved every thing for me: https://doc.pfsense.org/index.php/Why_can%27t_I_query_SNMP,_use_syslog,_NTP,_or_other_services_initiated_by_the_firewall_itself_over_IPsec_VPN Exact, iorx : in my prod config, C class IP addresses are all redirected to the LAN, whereas remote end of the IPSec tunnel is also 192.168. From my point of view (maybe mistaking, but why ?) this is normal, regarding routing : remote end of IPSec tunnel is "directly connected" for the pfSense, so not needing any static route. Have to recognize that adding a bogus internal IP to do it play may appear a little bit strange, though !  :D Cheers !

Thanks jimp. Unfortunately my results appear to be slightly different. I get this "none allows XAuthInitPSK authentication using Main Mode" error. Apr 20 21:23:21 charon: 09[IKE] <24> 166.xx.xx.xx is initiating a Main Mode IKE_SA Apr 20 21:23:21 charon: 09[ENC] <24> generating ID_PROT response 0 [ SA V V V V V ] Apr 20 21:23:21 charon: 09[NET] <24> sending packet: from 72.xx.xx.xx[500] to 166.xx.xx.xx[500] (180 bytes) Apr 20 21:23:21 charon: 09[NET] <24> received packet: from 166.xx.xx.xx[500] to 72.xx.xx.xx[500] (228 bytes) Apr 20 21:23:21 charon: 09[ENC] <24> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ] Apr 20 21:23:21 charon: 09[IKE] <24> remote host is behind NAT Apr 20 21:23:21 charon: 09[IKE] <24> remote host is behind NAT Apr 20 21:23:21 charon: 09[ENC] <24> generating ID_PROT response 0 [ KE No NAT-D NAT-D ] Apr 20 21:23:21 charon: 09[NET] <24> sending packet: from 72.xx.xx.xx[500] to 166.xx.xx.xx[500] (244 bytes) Apr 20 21:23:22 charon: 09[NET] <24> received packet: from 166.xx.xx.xx[4500] to 72.xx.xx.xx[4500] (92 bytes) Apr 20 21:23:22 charon: 09[ENC] <24> parsed ID_PROT request 0 [ ID HASH ] Apr 20 21:23:22 charon: 09[CFG] <24> looking for XAuthInitPSK peer configs matching 72.xx.xx.xx...166.xx.xx.xx[10.104.175.66] Apr 20 21:23:22 charon: 09[IKE] <24> found 2 matching configs, but none allows XAuthInitPSK authentication using Main Mode Apr 20 21:23:22 charon: 09[IKE] <24> found 2 matching configs, but none allows XAuthInitPSK authentication using Main Mode Apr 20 21:23:22 charon: 09[ENC] <24> generating INFORMATIONAL_V1 request 3999605427 [ HASH N(AUTH_FAILED) ] Android client is the main mode initiator, pfsense is the aggressive mode responder. The "auto" mode that I can find on my settings is the IKE version, not negotiation mode. I'm sticking with V1 due to the clients I'm using for road warrior use. I'm using IP address for the identifier. I think this is OK, right? Under the following guide it mentions that the identifier should match, but then I think I wouldn't get "found 2 matching configs" right? https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes (and yes, I have a site to site configuration and a road warrior configuration, hence 2 configs) Thanks!

Please read the docs and come back when you get stuck somewhere. https://doc.pfsense.org/index.php/Category:IPsec

@ermal: I have not tested this on 2.2.2 but for sure it will be usable on 2.3 of pfSense since even FreeBSD has had fixes especially for this in kernel side. Excellent! I'll give it a try with 2.2.2. Otherwise I'll wait for 2.3-snapshots.