Are you using IPsec or OpenVPN?

If FreeBSD supports that crypto chip, it should be used automatically by IPsec, but there isn't a real good test for that.

For OpenVPN, you can test with and without the cryptodev settings, and also with OpenSSL at the CLI:

See here:
http://doc.pfsense.org/index.php/Are_cryptographic_accelerators_supported

If you are just seeing the "cryptosoft0" line, however, that is not an accelerator.

I am now trying a Sonicwall on the remote side and it's doing the same thing, so something is amuck on the head end.  The Sonicwall has a special checkbox to tunnel all traffic over the VPN, including Internet traffic.  It creates the appropriate 0.0.0.0/0.0.0.0 match over the VPN so everything is definitely going over it, but I'm not getting an Internet (only internal) connectivity.  At this point, I don't believe it was a pfSense issue.

That isn't really an error, per se, but a warning. It is normal if you are using Aggressive mode, if I recall correctly.

Your problem is likely elsewhere, not with that message.

You should be pinging from a computer connected LAN A to computer connected to LAN B (or vice versa) not from one pfSense box to another.

This time including IPSEC configs

Pfsense 1.3 imbedded

Phase 1 Proposal
negotiation > main
identifier > My IP address
enc alg > AES-256
hash alg > SHA1
DH grp > 1
DPD
Lifetime 1800
Auth Method > RSA Sig
cert > present
Key > present

Phase 2 Proposal
Protocol > ESP
Encr alg > AES-256
Hash Alg > SHA1
PFS Key Grp > 2
Lifetime 1800

IPSecuritas

Phase1
Life > 1800
DH Grp > 768 (1)
Enc > AES 256
Auth > SHA-1
Exch > Main
Proposal Check > Obey
Nonce Size > 16

Phase 2
LIfetime > 1800
PFS Grp > 1024 (2)
Encrp > AES 256 AES 192 AES 128
Auth > HMAC SHA-1

ID

Local > Cert
Remote > Address

Auth Method : Certificates

switch to site-site OpenVPN and I think you will see your VPN problems disappear.   I love IPSec but I haven't found it to be reliable unless both ends have a static IP.  site-site OpenVPN has been rock solid with one end static and the other end dynamic.

Roy…

:-[ OK… I figured it out. I'm glad I didn't waste anyone else's time with this (I hope). The SonicWall apparently has hidden associated NAT rules that are added when a new VPN is created. The NAT rule I made seemed to mess things up. I just deleted that and most seems to work now.

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.