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.

haven' tried it. thing is if I enable IPSec VPN and keep trying, the users cant use IPsec clients. so i have to do it out of ours. if it is up n running, they don't need IPsec clients. cheers

What do you have on your Phase1 proposal checking?  If it's 'default' or 'strict' try changing it to 'obey'. From man racoon.conf(5): proposal_check level     specifies the action of lifetime length and PFS of the phase 2 selection on the responder side. The default level is strict If the level is; obey         the responder will obey the initiator anytime.     strict         If the responder's length is longer than the initiator's one, the responder uses the initiator's one. Otherwise it rejects the proposal. If PFS is not required by the responder, the responder will obey the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal.     claim         If the responder's length is longer than the initiator's one, the responder will use the initiator's one. If the responder's length is shorter than the initiator's one, the responder uses its own length AND sends a RESPONDER-LIFETIME notify message to an initiator in the case of lifetime. About PFS, this directive is same as strict     exact         If the initiator's length is not equal to the responder's one, the responder will reject the proposal. If PFS is required by both sides and if the responder's group is not equal to the initiator's one, then the responder will reject the proposal. The way I interpreted this for my troubleshooting was that if 'default/strict' are in force and the remote end reboots, the local end will ignore then incoming IKE until it own key lifetime expires.  Whether that's right or not, it worked for me and the Cisco ASA I was having as spat with!

Dhatz: With the tunnel saturated (currently pushing about 6 Mbps through it) I'm able to get an average of 79 ms which isn't too bad.  There are 14 hops between us and pinging outside the tunnel to the routers WAN IP gives me an average of 70 ms so the tunnel has little effect on my ping which is great. The remote site is using an Alix.2D13 (http://store.netgate.com/-P40.aspx) board.  And now that you mention it that site does say it comes with an OCF encryption accelerator.  I enabled the Crypto option as you suggest and ran the test again (mind that the tunnel is active so the results will be a little scewed) and got this: type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes md2                329.17k      708.05k      996.65k     1118.89k     1148.68k mdc2               549.04k      637.85k      659.26k      663.64k      655.26k md4               2289.13k     7854.97k    21920.32k    40305.54k    52503.86k md5               1753.12k     5772.70k    15143.99k    26220.17k    32645.97k hmac(md5)         2004.90k     6419.02k    16479.07k    26775.02k    33190.16k sha1              1475.25k     4074.76k     8455.58k    11490.71k    12844.19k rmd160            1468.63k     4096.69k     8569.98k    11790.03k    13403.30k rc4              22092.32k    26689.23k    27538.92k    27871.09k    27791.23k des cbc           5988.65k     6292.11k     6409.92k     6530.34k     6423.43k des ede3          2176.81k     2194.97k     2241.66k     2237.70k     2205.02k idea cbc             0.00         0.00         0.00         0.00         0.00 seed cbc             0.00         0.00         0.00         0.00         0.00 rc2 cbc           2854.43k     2940.76k     3002.53k     2941.11k     2999.06k rc5-32/12 cbc    16558.64k    19628.17k    20311.70k    20462.82k    20403.23k blowfish cbc      9999.56k    10856.40k    11422.71k    11376.40k    11248.24k cast cbc          8665.50k     9402.30k     9916.11k     9865.39k     9650.14k aes-128 cbc       5381.94k     5666.46k     5714.98k     5762.96k     5767.86k aes-192 cbc       4734.72k     4987.94k     4974.26k     5053.12k     5030.78k aes-256 cbc       4266.21k     4379.63k     4440.91k     4463.24k     4461.63k camellia-128 cbc     5725.98k     6261.62k     6313.85k     6278.99k     6223.47                  k camellia-192 cbc     4604.60k     4865.82k     4862.31k     4924.04k     4892.54                  k camellia-256 cbc     4502.63k     4857.29k     4870.93k     4862.82k     4926.56                  k sha256            1007.89k     2288.96k     3873.00k     4783.14k     5079.48k sha512             390.13k     1567.99k     2360.24k     3260.45k     3649.77k aes-128 ige       5449.03k     5863.30k     6074.94k     6049.77k     6101.76k aes-192 ige       4723.68k     5036.47k     5225.38k     5217.74k     5220.90k aes-256 ige       4214.93k     4501.45k     4583.63k     4629.43k     4645.62k                  sign    verify    sign/s verify/s rsa  512 bits 0.006918s 0.000674s    144.6   1484.0 rsa 1024 bits 0.031551s 0.001653s     31.7    605.0 rsa 2048 bits 0.179939s 0.004950s      5.6    202.0 rsa 4096 bits 1.113613s 0.016874s      0.9     59.3                  sign    verify    sign/s verify/s dsa  512 bits 0.005288s 0.006044s    189.1    165.5 dsa 1024 bits 0.014283s 0.016861s     70.0     59.3 dsa 2048 bits 0.045229s 0.053605s     22.1     18.7 I'm not sure I see much of an improvement, at least for that test.  Secondly, I switched over the tunnel to be as follows: IPSec Site-to-Site PH1: Auth:  Mutual PSK Neg: main Policy: Default Proposal: Default Enc: AES (128 bits) Hash: SHA1 DH: 2 PH 2: Proto: ESP Enc: AES (128 bits) Hash: SHA1 I'm not seeing much of a difference in the tunnel.  Is this the part in ADVANCED -> SYSTEM TUNABLES that I would change and if so what are some options that I should try?  Also, would I change this on both sides or just the remote side (As I have other VPNs to other sites as well that I don't want to effect yet)? net.inet.tcp.recvspace Maximum incoming/outgoing TCP datagram size (receive) default (65228) net.inet.tcp.sendspace Maximum incoming/outgoing TCP datagram size (send) default (65228) I really appreciate everyone's help and I'll do my best to provide the data you need to help me.  I hope this helps other in the future as well!

Possible but not likely, it would have to only block the ESP traffic in one direction. Kind of an odd behavior.

It's in the system log (Status > System Logs, or clog /var/log/system.log) If the line numbers do not match up, then it is likely an old error that hasn't been cleared.

Yes, the response to the other post is still valid. You can't predict/assign IPs to specific IPsec users. If you need that, OpenVPN would be a better choice.