This appears to be a routing issue:  I can do a packet capture on the IPSec interface of pfsense, and I can see incoming pings, and their destination: 12:52:18.793013 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1871, length 40 12:52:19.826520 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1872, length 40 12:52:21.329649 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP}: ICMP echo request, id 1, seq 1873, length 40 12:52:23.829947 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1881, length 40 12:52:25.326576 (authentic,confidential): SPI 0x083c9c1c: IP 10.1.53.1 > {LAN_IP2}: ICMP echo request, id 1, seq 1882, length 40 After I disconnect, and have cleared the ipsec log, this appears after a moment or two: Apr 28 12:49:50 racoon: DEBUG: pk_recv: retry[0] recv() Apr 28 12:49:50 racoon: DEBUG: got pfkey ACQUIRE message Apr 28 12:49:50 racoon: DEBUG: suitable outbound SP found: 0.0.0.0/0[0] 10.1.53.1/32[0] proto=any dir=out. Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501288: {LAN_SUBNET}/24[0] {LAN_IP}/32[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x28501648: {LAN_IP}/32[0] {LAN_SUBNET}/24[0] proto=any dir=out Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: sub:0xbfbfe728: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: db :0x285013c8: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in Apr 28 12:49:50 racoon: [Unknown Gateway/Dynamic]: DEBUG: suitable inbound SP found: 10.1.53.1/32[0] 0.0.0.0/0[0] proto=any dir=in. Im not sure if that is relevant or not.

Hello, Thanks for your advice. I changed this setting yesterday to 1400. Today, Snort and the ASA are reporting the same error… (One side is connected by fiber directly to the backbone and the other side has a cable modem with docsis 3) I don't really know what to do now...

Thank you! I was working with site-to-site VPN so intently I didn't even think to look at the mobile VPN page.  All is well now. Thanks again!

Sloved it was beacouse ipcop firewall which already had that connection with another ip cop so i try to connect to another location and it works i think i need to restart this ipcop to clean his memory and it should work. THX

Ok, then can PFSense handle having Phase 1 and Phase 2 in the same subnet?  On the local side the p1 IP = CARP VIP (WAN if)  p2 IP = IP Alias VIP (WAN if) NAT 1:1 WAN if WAN rules created IPSEC rules created Still does not come up.

I have now managed to get what I can assume is a stable connection between both locations using IPSEC.. I am just a bit lost how to resolve remote hostnames. I have added a remote device on location 2 to a computer on location 1 hosts file and I now can ping across the IPSEC tunnel to that device. I am guessing I now need to look at some sort of DNS that will resolve hostnames automatically and accessable from both locations as adding hostnames will be a bit of a pain.

Double, Tripple and more Times checked. Another try this morning with DN, but always ERROR: couldn't find the pskey for ERROR: failed to process ph1 packet (side: 0, status: 6). Luckily this is the only Site2Site with Dynamic IP on the Remote Site. I changed all other Tunnels to Peer identifier = Peer IP address to make them work. Has anyone successfully established a Connection between PfSense 2.0.2 and Linux Openswan U2.6.21/K2.6.30.10-105.2.23.fc11.i586 (Fedora 11) or an LANCOM Box with an Peer identifier other than Peer IP address?

That sounds a lot like what would happen if your sync process started going nuts with huge numbers of connections and maxes out the state table. Check your RRD States graph vs. your states limit.

Thanks! So in this particular case when this issue cropped up, I had 2 VPNs drop between 3 pfSense machines. FW-A: Single pfSense box FW-B: HA pfSense boxes FW-C: HA pfSense boxes There are 2 IPsec VPNs: 1 between FW-A <-> FW-B and 1 between FW-A <-> FW-C. I did find that the "Disable all auto-added VPN rules" was enabled on FW-A and FW-C which is now disabled, but the setting was already disabled on FW-B. Looking at /tmp/rules.debug under "VPN Rules" I see rules on both FW-A and FW-C, but none under FW-B. Any idea why? I've double and triple checked the "Disable all auto-added VPN rules" setting and did note that when enabled, a comment under VPN rules is noted as disabled so I know the setting is being noted.

Recent snapshots offer IPsec failover capability (using gateway group), however you might find it better to migrate to OpenVPN and OSPF.

I understand, thanks cmb!! thanks jimp!!

"racoon: ERROR: phase1 negotiation failed due to send error" is what happens when you have a misconfigured PPTP server and a client disconnects. PPTP server should never use an assigned IP of any sort, especially WAN, as its server IP.

I spoke too soon.  While the link you provided is correct in that this will allow the gateway to directly connect to systems on the others side of the VPN, it also appears to be causing routing issues for every box that is not the gateway when it's enabled. Prior to adding the static route according to the link, I can ping any system (on B network) from my desktop (on A network), however, any attempt to ping a system (on B network) from the gateway (on A network) itself will fail. If I then add the route, I can ping any systems (on B network) from the gateway (on A network), but my desktop (on A network) can no longer ping any systems (on B network).  I have noticed that sometimes it appears as though one packet "slips by" but from that point on it's destination host unreachable… oddly, the response is coming from my desktop's IP (not any gateway).

Hi, I'm running 2.0.2 with racoon 0.8.0. The right combination of loss of connectivity to remote endpoints seems to be triggering the crashing. I've submitted a bug report here: https://sourceforge.net/tracker/?func=detail&aid=3603844&group_id=74601&atid=541482 I also submitted this to FreeBSD a while ago, but it got closed.  Should I open up a new one? http://www.freebsd.org/cgi/query-pr.cgi?pr=168104 It seems like the more Phase1's not establishing, the more likely racoon is to segfault.