A FreeBSD developer is asking me for backtraces, but they don't seem to be that informative. Aren't there separate binaries with debugging symbols that you are supposed to use when doing this? GNU gdb 6.6 [GDB v6.6 for FreeBSD] Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB.  Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd8.1"... (no debugging symbols found) (no debugging symbols found) Core was generated by `racoon'. Program terminated with signal 11, Segmentation fault. #0  0x080672a9 in ?? () from /libexec/ld-elf.so.1 (gdb) bt #0  0x080672a9 in ?? () from /libexec/ld-elf.so.1 #1  0x2854de48 in ?? () #2  0x00000000 in ?? () (gdb) quit

Hi Rudivd, I am trying to connect my Mac OS X 10.8 to pfSense 2.1 RC. Can you please tell me how to setup the connection? I following some setting from http://doc.pfsense.org/index.php/IPsec_Road_Warrior/Mobile_Client_How-To but not work. It show server no response and the pfSense logging "ERROR: exchange Identity Protection not allowed in any applicable rmconf." Thanks, Edward

Very strange now. Now I can see some Bonjour services from the remote side in Safari and in an app called Bonjour Browser. But they are not reachable nor can be resolved. It seems that some information come through the vpn tunnel but not all needed stuff. Any idea?

I took a stab at fixing this problem.  Details here: http://redmine.pfsense.org/issues/1351

Ah, didn't know any of that – thanks for the clarification. Good to know about the pings bringing up the tunnel!

Unfortunately there is no way to have a second mobile config, only one is supported. If you need the same one to answer on both WANs, you might be able to accomplish that by forwarding udp/500 udp/4500 and esp from WAN2 to WAN1, but that would most likely break any other non-mobile tunnels you also have on WAN2. Don't quote me on that though, pure speculation that it would even work.

Did you ever get this worked out?  I am having a similar issue…

We resolved our issue by checking that no intermediary device was blocking ESP protocol traffic. Even though SA "exchange/handshake" was completed and DPD transferring over UDP 500… ESP transfer was our root cause!

Thanks for your advice. We believe that it is working now with some minor changes to the pfSense end. We have gone back to basics on IPSec. Since the Security Associations (SA) were being established between the two sites, but traffic was flowing OUTOF the pfSense (to somewhere) but not flowing INTO the pfSense from the second site (from y.y.y.y);  and no traffic was being received at the second site. We assumed that there must be some device in the way that was blocking the data traffic. Since the data traffic is handled on ESP Protocol, something must be blocking that. Changing the router configuration, so instead of using open ports (UDP 500) for NAT, we tested by using a DMZ/address map. As soon as this was changed, data started to flow and SSH connections could be made. We also made it more robust by adding a gateway definition for the LAN interface and Firewall rules to pfSense to run LAN 172.20.0.0/16 via the LAN GW. Belt and braces really (plus enables better fault finding). During this process we ruled out red herrings such as: IPV6 redirection issues Routing table issues on the SSG140's Firewall policies on the SSG140's Scrub This experience leads me to favour pfSense over packaged Juniper products (e.g. SSG140): Better overall fault diagnosis than Juniper Better tracing of traffic Better tuning of configuration parameters Better log information

http://doc.pfsense.org/index.php/IPsec_with_Multiple_Subnets#pfSense_2.0.2B

@gamejia: For those interested in a very ugly workaround, I created a script that runs every 5 minutes (using cron) and cleans up the IPSec SAD and SPD entries if there are no users using IPSec. <snip>Please keep in mind that this is still a WIP and I plan on cleaning it up more in the future if no fix is available. I plan on comparing the entries returned by "setkey -Da" and "setkey -DPa" to the values returned by racoonctl and only remove the SPD entries that are causing problems.</snip> Thank you for posting the script. It has been really helpful, and has made the VPN usage in our small network more predictable. Ideally this should be handled at the pfsense end without using this workaround, considering if there are more number of users, then things can get complicated. I was not able to find any bug-report for this; is anyone aware of any bug report filed - else I'll go ahead and do it.

Do you have VM's running?