So, like… how about posting the contents of /var/etc/ipsec/racoon.conf file?

I have been having the same problem. When I just connect my Netgear router, all works well.

None of that really applies to Mobile. There isn't a way in IPsec currently to restrict access for a given IP/PSK in the way you're after. If this is for site to site, use individual tunnels, not mobile. If it's for mobile clients, the Phase 2 entries are only really used if you check the box to supply a list of networks to the client, and then only if they obey that list. Mobile setups let the client specify what they want to send, the server can't really restrict that (except with firewall rules)

Thank you dotdash! I didn't cross my mind that I could set the source subnet (our side) to the customer's server (/32) instead of the subnet. And I will have a look at NAT too.

Hello iamzam, thanks for your reply. I've added the rule to allow AH but it also didn't work.

…and with that response, I honestly figured it out.  Sheesh!  Why didn't I remember to allow UDP across my tunnel?  DNS works fine now.  Thanks!

Follow up: When debugging and redacting previous post I've disabled a second IPSec tunnel (one for point-to-point VPN, not mobile clients) and now mobile client access seems to work just fine (using Shrew Soft VPN Connect software and builtin iOS client). ("Unknown Gateway/Dynamic" log message is still there though) I'll look into the settings of this second tunnel later (time to confirm that at least everything is OK with one tunnel).

@kapara: Been doing some research on AESNI and it looks like even using a corei5 proc can provide significant improvement.  Anyone test AESNI on pfsense yet? Yes, don't bother.  AES-NI makes no difference at this point, though I wouldn't buy a CPU without it as better support is in the pipeline.

I would suggest checking that you have correctly specified the Search Scope and Base Containers properly. PM me if you still have troubles - I have the Microsoft AD part of IPSec working, but now I'm getting asymmetric routing I suspect. :(

Aye, that may be. We've got a heavily virtual environment so for us its zero marginal cost to spin up another VM for that purpose. Though I am intrigued by OpenVPN. That it can export a setup executable is really cool. I might just go with that instead. Other thoughts?

chflags schg filename If you want to be sure that command changed attributes correctly: ls -lo filename -rw-r–r--  1 root  wheel  schg 193 Aug  1 09:20 filename After, if you need to change it again, it will be sufficient to remove protection attributes with: chflags noschg filename

Do both of your WAN interfaces have the same gateway, perhaps?

I am having the same problem with this, it will not re-establish from CISCO side, no problem from pfsense to CISCO site

I lately had repeated problems with IPsec tunnel (well doing over months), that after the provider did some "service" the tunnel was not functional (no ping, no data passing) for some hours, although the tunnel was successfully established according to racoon protocolls on BOTH sides. Strange, strange, maybe NSA had no capacity to handle more man-in-the-middle? :)

I've put accept on all interfaces and log, but no logging of drooped or accepted udp packets. At closer look to the UDP packets I could see that the frame header has the 802.1Q part with VLANID 0. The old router accepted this packets, but not pfsense.

I'm honestly surprised that they can block OpenVPN. We have ours setup so it tries UDP on a weird port –- If that doesn't work it will revert to TCP port 443 so it is very difficult to distinguish from HTTPS. Even if you can't make a tunnel with SSH, I'm sure you can make an SSH tunnel back to a server that can handle SSH tunnels. Honestly we stopped handling OpenVPN on PFSense due to everyone being disconnected when the firewall fails over.