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.

I am by no means an expert. But since the experts have not had time to respond, I thought I'd give my two cents as I've had a pfsense site to site ipsec tunnel working for sometime.  In phase 2 what did you put for local network and remote network.  I have local subnet selected for the first and the address  ip for the remote network.  I believe this sets up the routing needed from one subnet to the other.  Since you are going from WAN interface to another router as your default gateway, there was an entry in the pfsense guide that mentioned you might have to setup static routes from one network to the other. For your layout, pfsense is not the gatway router.  There are some considerations in the guide for that. I'm not sure if posting from the guide is allowed for copyright reasons. I will try to summarize.  A static route could be entered into the gateway router that will redirect traffic destined for the far side of the tunnel to the pfSense router. There may be some issues with this and it goes on to recommend that pfsense be made the default gateway of both networks.  I hope this helps.  FYI, both ends of my tunnel have pfsense as the gateway.  I hope this helps.

Oddly enough I had this exact error and happen to have UPnP enabled. Though my work around was to change "My Identifier" to Dynamic DNS instead of My IP address.

Great. thanks for the reply!

Have a chek at the IPSec logs on each end and I'm sure you'll find the answer :)

Ok, I figured it out after hours of investigating and with some help from the guys at the ipsec-tools-users mailing list. Since this information is not clearly stated anywhere, I'll sum it up here (at some point I think this needs to be added to the wiki) When using an IPsec site-to-site with RSA validation, both "My identifier" and "Peers identifier" must be set to "ASN.1 Distinguished Name". If you leave them blank, the ASN1DN value will be taken from the certificate (own certificate for my_identifier and peer's CERT on the received payload for peers_identifier). Usually, you want to leave the "my_identifier" value blank, so racoon will send the value from the certificate itself. Most gateways will plainly refuse your connection if the sent value does not match the cert you are sending, which makes perfect sense. Now, if you want to tell racoon to only authenticate connections FROM a specific certificate or set of certificates (instead of anything signed by the same CA), it can be done with the peers_identifier option. What you need to type in the box is the exact string from the subject field of the certificate. You can get this value by directly looking at the racoon log and watch for the received payload, or parse the remote certificate with: openssl x509 -in certificate.pem -text Where "certificate.pem" is the certificate you want to allow. You can also allow a set of certificates by using wildcards. Individual component values of an asn1dn identifier may be specified as * to match any value (e.g. "C=XX, O=MyOrg, OU=*, CN=Mine"). Bear in mind that if the information includes special characters like – ,=+<>#;  – , they will need to be escaped by a backslash. The final caveat for this to work is that there is an additional option that needs to be set on the racoon.conf file: verify_identifier on; If this is not set, racoon will allow the connection even if the DN does not match. At this point, the pfSense webGUI does not set this flag, and since it defaults to off, makes it allow any cert to connect. Of course you can add the option to the racoon.conf file and manually restart racoon, but it won't survive a reboot. In my particular case, I also had to manually delete all the SADs and SPDs on both ends since it looked like they were cached or something, the VPN was connecting no matter what I set as the peers_identifier. I will raise a request to add a checkbox for the "verify_identifier on" on the webGUI. As usual, hope this helps anybody :) Regards! EDIT: added a feature request on redmine: http://redmine.pfsense.org/issues/2904

Thank you Jim, I appreciate the reply. The remote side is a Palo Alto firewall which is capable of both SPD-based ("policy-based") as well as so-called "route-based" VPNs.  I'm guessing there is no way to do a route-based VPN with pfSense? I have the broad VPN tunnel in place because I was trying to avoid adding an SPD for every remote subnet at corporate - these are all MPLS sites on /24s that are sent back to the corporate Palo Alto via BGP.  Rather than me manually having to maintain the tunnel and add SPDs each time we add a remote site (which is regularly as the business keeps growing), I just used /16s in the tunnel with the assumption that it would obey static routes and more specific routes would take precedence over the tunnel (like basically every other router/firewall I've worked with). It is very handy for me to be able to poke the remote MPLS sites across the tunnel so I can access things from home without an additional stop between (RDP / SSH to something at the office first). If I could do a route-based tunnel, I could then also carry a routing protocol (either OSPF or BGP) and get the correct set of routes directly from the Palo Alto instead. If pf can't handle this, then I guess I'll have to consider a secondary router just for the VPN traffic.