NAT-T and pfSense

phaesler

According to http://doc.pfsense.org/index.php/Does_pfSense_support_NAT-T%3F, pfSense 1.2.3 does not support NAT-T.

We have an IPSEC tunnel between a pfSense firewall and a Fortigate router. The Fortigate router (which does support NAT-T) is behind a NAT firewall.

I'm not asking for assistance, because we actually have the thing working. It's just that none of us can understand how, given that the pfSense end does not support NAT-T (which needed to be enabled at the Fortigate end for the link to work).

Is it actually the case that pfSense 1.2.3 has a partial NAT-T implementation, such that it can interoperate with an end-point that has it fully implemented, as in our case? Or is there some deeper IPSEC subtlety at play?

I'm happy, but confused - I can't see the emoticon for that.

phaesler

OK, here's some more info - and this time an actual request for help (if anybody can actually do so.)

When we first got the tunnel up, it was highly unstable - typically lasted 20-40minutes. After that it would go into an endless cycle of phase 1 negotiations. It would then require an extended dance of resetting both ends of the tunnel until eventually it would come back up again.

We then reduced the phase 2 key lifetime from 3600s (1 hour) to 600s (10 mins). The same black-magic dance was required to get the tunnel up, but once up, it actually stayed up - this time for 8 hours. It is almost certainly no coincidence that this the precise value of the phase 1 key lifetime.

This morning we tried extending the phase 1 key lifetime to it's maximum allowed value of 48 hours - the tunnel barely lasted a minute. We are currently a few minutes into testing it with a value of 16 hours. I'll keep you all informed of how that goes.

So my questions:

Does any of the above make much sense?
Is it likely that the incomplete NAT-T support is the problem? In particular, does this explain the black magic reset dance required to get the tunnel up in the first place?
Is there anything else we can try that might get the tunnel to stay up, or failing that, to come back up reliably? (The tunnel is being initiated by the Fortigate router behind the NAT firewall)
Is it just a complete fluke that we have made as much progress as we have, and we really need to completely reassess our approach?

Thanks.

phaesler

As far as I can gather at this stage the "incomplete support" is that the IKE daemon used by pfSense (raccoon) DOES support NAT-T, but pfSense itself does not. I do not understand the details of the interaction between raccoon and pfSense to explain further.

One can establish a tunnel (with a bit of black magic)and keep it up for an extended period (with some careful configuration), but it will always die on the phase 1 key renegotiation.

kc8apf

What NICs are you using? Do you have any tcpdumps? What about the phase 1 renegotiation is failing? Are you seeing no response from one end or is it an actual failure response?

Vorkbaard

Phaesler, 1.2.3 did support NAT-T for a while but later versions of 1.2.3 removed the feature because there were too many problems with it.

More info: http://blog.pfsense.org/?p=497

1.2.3-RC3 now available!
After several months since the last official 1.2.3-RC release, because of some tough issues in the underlying software that are now resolved, 1.2.3-RC3 is now available.

The final release will be coming very soon, please help test.

The major changes since 1.2.3-RC1:

NAT-T support has been removed. Adding it brought out bugs in the underlying ipsec-tools, causing problems in some circumstances with renegotiation and completely breaking DPD. These issues are fixed in the CVS version of ipsec-tools, but it’s still considered alpha, and we found different problems when attempting to use it instead. NAT-T will be back in the 2.0 release, where it’s not as much of a pain since NAT-T is now in stock FreeBSD 8.

bkm

I don't think that the renegotiation problem is NAT-T related. There are two things that I would check. The first would be to check the box next to

System - Advanced - Prefer old IPSec SAs

I don't know if there is a similar option in the Fortigate.

If that does not fix the problem, I would turn off the PFS key group in your Phase 2 proposal.

If that does not fix the problem there are a couple of long threads listed below that may help you.

http://forum.pfsense.org/index.php/topic,16274.0.html

http://forum.pfsense.org/index.php/topic,20043.0.html

cmb

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.