This old thread comes up high on Google for this message. For the sake of those running into this in the future, "racoon: ERROR: failed to get sainfo" means you have a phase 2 mismatch. Best way to determine what is to run racoon in the foreground in debug mode with: racoon -F -d -v -f /var/etc/racoon.conf

Just a precision, in my first post i said we have about 40 tunnels, i must precise that the pfsense box is the only one with a fixed ip, every other endpoints are using dyndns, so the racoon config is reloaded quite often (the ip's are expiring every 24h) Generally the ip update process is working fine,but sometime it crashes as you can see… May the hostname itself be the cause ? I don't know exactly what your php script is doing with the racoon config, I suppose it's replacing the modified IP by the new one, so it should not be the cause...

You'll have to learn a little about BGP and routing to make it work; but basically you just setup openbgpd on each site announcing its routes to two neighbors at the other side – each neighbor configuration would be using the openvpn IPs for one of the redundant links.  You can use 'set metric 10' (or 20 or ...) to bump the "cost" of one link over the other.  (There are other ways, too, but 'set metric' is easy and works fine in small setups). Each site will have its own AS -- private AS numbers are between 64512 and 65535.

This is not a support forum for ipsec-tools and racoon on anything except pfSense, which is running FreeBSD (not a Linux variant). The configuration on pfSense is GUI-based, and the users don't directly edit the configuration file. You should try posting to a forum or mailing list that is specific to your needs.

Got the tunnel up after playing with the settings and upgrading to 1.3.3. Only traffic flows just from one site to the other not in reverse i think al the traffic get natted. Can't adjust any settings on the checkpoint site tommorow i check it out.

I have seen this issue in the forum with pfsense as well. The issue was not resolved before the user's need was eliminated. The only difference was that the first client would maintain the connection and others could not connect. If I remember correctly, there were a couple of suggestions. One was to set up a static port for outbound NAT so that the port was not changed when going through the pfsense firewall. The second suggestion involved ensuring that the customer site supported NAT-T. I would be interested in hearing whether the static port option resolves the issue.

I finally broke down and got the book out and read through the instructions.  Turns out I forgot to put rules FROM each VPN tunnel segment, I had the rules TO the segments but missed one part. Everything works great now.  Wonderful book btw.

If the connection required NAT-T, it just plain wouldn't work. NAT-T isn't compiled in at all, it'll be refused if proposed or attempted, there is nothing "partial" about the support (see snippet posted by Vorkbaard above). Even with that device behind NAT you probably don't actually need NAT-T, though that depends on what kind of NAT device it's behind, and possibly a number of other things on their end. If it negotiates, but doesn't re-negotiate, it's not related to NAT-T. It could be related to many other things. Logs from both ends may help. In these kinds of scenarios with any devices where there are difficulties with two different vendors (regardless of vendor) you may need to crank up the log levels on both ends, which on the pfSense end means running racoon in debug mode.

This shouldn't be a problem. Read the guides or buy the pfSense book. In a Multi-WAN setup, you would need to use only one WAN for the tunnels. This info is listed in the docs also. http://doc.pfsense.org/index.php/Category:Howto

It looks like a mismatched phase 2 key. The error logging does not always provide definitive answers though. If you provide your config, you will more likely get a better response.

Hi, just had to register to say thanks. I have been using. pfsense 1.2.3 on watchguard x1000 hardware and been trying to tunnel with both m0n0wall and sonicwall. the tunnel has always come up no problem but the damn traffic didn't go through! but changing to md5 instead of sha1 made the difference! crazy really and i have been thinking about changing from pfsense just because of this. so thank you.

I had this problem a few times after upgrades: http://forum.pfsense.org/index.php/topic,15878.msg94828.html#msg94828 during the last upgrade to 1.2.3 Release, it was fine, no problem. If i remember, all i needed to do was go into my configuration and save it again.

There are no software limits. There are some pfSense installations out there that have 200-300+ tunnels going at once.