Its would simultaneously be cool and uncool if pfsense had a openvpn package GUI that could be presented to the world that would allow a user based on their credentials to login and download a config file for their account.

Some people really want to allow this, even though its not the most secure way to roll.  Brings the security of the VPN down to a password.

If you messed up the settings on the manual outbound NAT for port 500, that would do it.
You need to have a setting at the very top to pass port 500 as static port.  I had many subnets, so I put a rule in to pass a /16 as static on that port to take care of all the /24s.  That rule should have been autogenerated, but it would be very easy to mess it up or to put in a rule before it that breaks it.

Thanks for your reply, was away from my machine.

Settings are IDENTICAL, like I said it only happens for 1 particular watchguard.  Funny thing is I had to change the NICS out due to some interface errors 6 weeks or so ago, prior to that swap the tunnel never dropped ( I think because the tunnel had restricted traffic ).  Once I changed that NIC, the errors cleared and the tunnel had more traffic on it, now bringing that firewall down randomly.

Firewall is not identical, I started updating them one by one a day or so ago.

ISPs, nothing has changed.

Tunnel shows up in PFSENSE, but no pings are successful.  I can get into the Watchguard however, from another location.  IE, no ping from the PFSENSE box to the down watchguard, but if I am in another watchguard I can ping the "down" firewall just fine.  Very odd and frustrating.

Going to clear the states tonight.

Once again thanks for your response, not sure what else I can check

***Went down this AM.

Sep 5 05:56:12 racoon: [site1 to site2]: [66.185.28.115] INFO: DPD: remote (ISAKMP-SA spi=d8bd5fa5f02159cb:2d3df88062dc7094) seems to be dead.
Sep 5 05:55:37 racoon: [site1 to site2]: INFO: ISAKMP-SA established 78.185.55.234[500]-66.185.28.115[500] spi:8c610366f1e444b6:e167895836b7b267
Sep 5 05:55:37 racoon: INFO: NAT not detected
Sep 5 05:55:37 racoon: INFO: NAT-D payload #1 verified
Sep 5 05:55:37 racoon: [site1 to site2]: [66.185.28.115] INFO: Hashing 66.185.28.115[500] with algo #2
Sep 5 05:55:37 racoon: INFO: NAT-D payload #0 verified
Sep 5 05:55:37 racoon: [Self]: [78.15.55.234] INFO: Hashing 78.15.55.234[500] with algo #2
Sep 5 05:55:37 racoon: INFO: Adding remote and local NAT-D payloads.
Sep 5 05:55:37 racoon: [Self]: [78.15.55.234] INFO: Hashing 78.15.55.234[500] with algo #2
Sep 5 05:55:37 racoon: [site1 to site2]: [66.185.28.115] INFO: Hashing 66.185.28.115[500] with algo #2
Sep 5 05:55:37 racoon: [site1 to site2]: [66.185.28.115] INFO: Selected NAT-T version: draft-ietf-ipsec-nat-t-ike-02

bumping this thread, hoping we can get resolution I'm seeing the same error, I've got multiple tunnels up but I'm having disconnect issues with them.  The SAD entires still appear with setkey -D but the counters show no traffic coming from the remote site.  The other site is not a racoon/pfsense device.

Sep  4 08:34:44 vpn racoon: [184.71.132.154] ERROR: delete payload with invalid doi:0.
Sep  4 08:48:45 vpn racoon: [aaa.aaa.aaa.aaa] ERROR: unknown Informational exchange received.
Sep  4 11:10:39 vpn racoon: ERROR: phase1 negotiation failed due to time up. 4da0a464cfd021e5:d86e8547b43ac0af
Sep  4 12:56:54 vpn racoon: [aaa.aaa.aaa.aaa] ERROR: unknown Informational exchange received.
Sep  4 13:48:59 vpn racoon: ERROR: pfkey DELETE received: ESP me.me.me/me[500]->aaa.aaa.aaa.aa[500] spi=246925167(0xeb7c76f)
Sep  4 13:48:59 vpn racoon: ERROR: no iph2 found: ESP aaa.aaa.aaa.aaa[500]->me.me.me.me[500] spi=199400304(0xbe29b70)
Sep  4 13:49:10 vpn racoon: ERROR: no iph2 found: ESP me.me.me.me[500]->aaa.aaa.aaa.aaa[500] spi=166831041(0x9f1a3c1)
Sep  4 13:51:16 vpn racoon: ERROR: no iph2 found: ESP me.me.me.me[500]->bbb.bbb.bbb.bbb[500] spi=1807220792(0x6bb80038)
Sep  4 13:51:16 vpn racoon: ERROR: no iph2 found: ESP bbb.bbb.bbb.bbb[500]->me.me.me.me[500] spi=36532152(0x22d6fb8)
Sep  4 13:55:02 vpn racoon: ERROR: pfkey DELETE received: ESP me.me.me.me[500]->ccc.ccc.ccc.ccc[500] spi=187913932(0xb3356cc)
Sep  4 13:55:02 vpn racoon: ERROR: no iph2 found: ESP ccc.ccc.ccc.ccc[500]->me.me/me/me[500] spi=213876149(0xcbf7db5)

Here's one of my racoon.conf entires for Site A

remote aaa.aaa.aaa.aaa {
        exchange_mode main;
        lifetime time 28800 seconds;
        proposal {
                encryption_algorithm 3des;
                hash_algorithm sha1;
                authentication_method pre_shared_key;
                dh_group 2;
        }
        generate_policy off;
}

sainfo address 172.29.0.0/28 any address 192.168.0.0/23 any {
        pfs_group 2;
        lifetime time 28800 seconds;
        encryption_algorithm 3des;
        authentication_algorithm hmac_sha1;
        compression_algorithm deflate;
}

Have you checked here?

http://doc.pfsense.org/index.php/IPsec_Troubleshooting

That only works on 2.1, and on 2.1, a gateway group will show up as an interface choice for the tunnel.

Well I sorted it out myself, not perfect but better. I enabled MSS clamping on the IPSEC tunnel under Advanced and set it to 1300. That has made transfers from Windows servers work well and it keeps a steady 95Mbit/s transfer, but it also affected the Qnap NAS that now has a bursting traffic graph. I guess it´s fine as the Qnap still averages about 80Mbit/s. The MSS clamping was enabled previously with the default 1400 value and that worked a lot better for the Qnap.

Anybody that could give me a hint on how to get them both to work properly over the tunnel?

I´m also not sure I understand how this works. I could ping both the Win Server and Qnap over the IPSEC tunnel with ping -f -l 1472 x.x.x.x without getting fragmentation both ways. Why would I need to clamp the MSS all the way down to 1300 for the Windows server and not for the Qnap? What other overhead is there to subtract from 1472?

I Still can ping with a 1472 lenght max before fragmentation  even now when the clamping is set to 1300, is that how it should be?

I´m open for someone to educate me on how this works and how to properly calculate this.

Thanks,
Jesper

Whoooooo

worked. OK so for posterity's (and googles) sake, the solution was evident in PFsense 2.1 (RC0+), in the PH2 properties of the IPsec tunnel under local network you can provide the LAN subnet, and the 'nat/binat' address being the external WANip.

My only conclusion is that since the ipsec routes are kernel routes they don't get applied with outbound nat rules (which is what I was trying).

I have this occasionally too.. seems not to affect anything.

There is a whole bunch of documentation available here. Absolutely not apparent what your setup is, and frankly, this whole thing should be taken to Windows Azure Forums way before you start debugging pfSense stuff (basically until MS has determined this to be a BSD-specific issue at least.)

Great job!

Once again thanks.

(I think i found the patches applied https://github.com/pfsense/pfsense-tools/blob/master/pfPorts/ipsec-tools-0.8.1/files/ipsec-nat.diff)

@cakewipe:

I have added my documentation to google docs so anyone can see it.

Here is the link for pfSense Router settings
https://docs.google.com/file/d/0B2zOOBoh3isOSmtYakVEc3ZNWDA/edit?usp=sharing

Here is the link for Shrewsoft, Android, iOS Clients.
https://docs.google.com/document/d/1Pl21sk7ckU6dSqgxtXu6iNIv8-60bv7AFFVUQwdJ_WE/edit?usp=sharing

Please leave comments if this is helpful so I will know not to remove the documents from my share.

Hello Cakewipe,
    Thanx for your work here.  I am having a similar problem you had.  When the client connects, there is no route handed to the client according to ipconfig on the windows box.

I see not route to that network on the pfsense box.

So looking over your doc above it looks like you are still using the static route, is that true?

Did you have to use PSK-Xauth?  It wouldn't work with just PSK?

I looked over your doc

I have got this going now. But what confused me is the abscence of a start tunnel button. The pfsense system should be able to send a packet through the tunnel to start it.

http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0

That reads more like there is a problem with either the phase 1 or phase 2 config than the error I was talking about.

The error I was concerned with did allow connections, it just didn't reliably reconnect in a timely manner after a short disconnect.