same problem here with mobile Clients using ShrewSoft on ver 2.0 final nanobsd, no additional packages installed tunnel works well once then the tunnel establishes but nothing flows through it;  i need to restart racoon to get it working again

Resolved. Here's the nitty gritty. I few days ago i had installed/uninstalled squid/lightsquid. Lightsquid had not uninstalled properly and had the monitor hanging. So none of the rules i was adding was getting written. Installed uninstalled squid/lightsquid again. Lef the same rules again. Ipsec now works. Thank you all.

Fixed! Shrew works perfectly for me on Linux now. In summary, I had to disable spoof protection. Here is what I had to do in order to get it working: Modified /etc/sysctl.conf Modifed /etc/sysctl.d/10-network-security.conf Changed .rp_filter=1 to .rp_filter=0 for all occurances Rebooted I also posted more information on my website. All devices are now working through IPsec with PSK and XAuth.

There are at least 15 different systems running IPsec to IOS on 2.0 release that I've setup personally, probably hundreds or thousands total, so it's not really that easy. I first suspected some kind of issue with the crypto card, but completely changing out hardware, unless you moved over the crypto card (did you?), would probably rule that out. That linked thread has no relation at all to what you're seeing, the patch that caused that is long gone.

@wangpro: lan address is 192.168.2.10, ipsec client network for ipad is 192.168.2.180/24 You need to use a different subnet for IPsec.  Example, 192.168.3.0/24. My Ipad works perfectly with 2.0.

@srs: My question is if someone think this is possible to me to keep loadbalancing and have all this traffic on a VPN using IPSEC? It's been a while since I've looked at a Sonicwall firewall.  If it has the ability for a failover (alternate) VPN IP address, then you could set a gateway group in pfSense set the second WAN interface to Tier 2. That should work because both firewalls would monitor an IP for each failover.  I'm just not sure with Sonicwall, it's been a few years for me.

Thanks so much for your help :-) I'll give this a go and see what we come up with.

Unless someone has seen this before, you will probably need to post more information.  Such as, what version of pfSense you are using, what did you do when this occurred, etc.

@ttblum: do I also need to add a rule allowing UDP port 4500 traffic? That depends on if you are using NAT-T. Look in your tunnel configuration to see if you have NAT Traversal enabled in pfSense.  It is in the advanced options at the bottom of the phase 1 policy. If both firewalls have NAT-T on, then you will need to allow access over UDP 4500, or disable it on both.

IPsec connections don't stay up unless you're sending traffic across them. Though that generally doesn't matter, as soon as something tries to send something across they'll come up within 1-2 seconds. As long as the local subnet includes one of the IPs assigned to the firewall, the ping host will keep it up.

If you can still SSH, you can hit the web interface via a SSH tunnel and fix it. Item #6 here. http://doc.pfsense.org/index.php/I_locked_myself_out_of_the_WebGUI,_help! You can also manually edit the XML via SSH but that's error prone if you're not familiar with it, could really break things.

ok, the only place I saw that could have possibly overridden the chosen pfs_group setting would have been in there. I don't see any other way that what you choose isn't ending up in the racoon.conf

Yes I am.  Ok so I will change that to a local IP and test again.  Thank you for posting that information.

Solved System > Advanced > Misc. > Enable MSS clamping on VPN traffic The problem was already large RPC packets becoming too large as a result of IPsec encapsulation.  After reducing the WAN mtu and messing up all my connections, a colleague suggested I try this setting.  It works great with the default value of 1400. Hopefully this helps someone.

That error is not your problem. That error is harmless. Mobile tunnels have no remote gateway, so that error isn't really saying anything significant. The system log is not where you should be looking, check the IPsec tab.

I will have to recreate everything to get a log dump. I guess what I mean when I said they do not contain anything decipherable to me is that through all my changes, I muddied the waters so much. I will post back when I have recreated the issue.

Good to hear

Is 192.168.190.x the LAN subnet of the PFsense or an additional network behind the PFsense?  You might need a rule on your LAN interface permitting ALL LAN subnets to any.  Also, if it is an additional network, you need a route on your PFsense to point 192.168.190.x out the local LAN interface. Same questions would apply for the other side of the tunnel as well…

It is normal for it to try, yes, but if it's bound to the CARP interface the traffic won't normally ever make it out of the box, so it does nothing but fill the logs on the secondary with attempted connections.