[Swan-dev] Cisco NATT bug

Paul Wouters paul at nohats.ca
Thu Mar 20 17:50:34 EET 2014


On Sat, 8 Mar 2014, Paul Wouters wrote:

> I've talked to some people about the Cisco NAT-T issue. It is known bug
> in older firmware. The bad firmware uses the draft NATT for one payload
> (NATD I believe) and the RFC version of second payload (NATOA). This is
> why suppressing the RFC VID works around this issue, because than both
> sides use the draft NATT numbers.
>
> One workaround is to not show the RFC NATT VID when we see the Cisco
> VID, and rely on the draft VIDs for Cisco. Than we would not have to
> add a configuration option. But we would be stuck forever with draft
> codes. Perhaps it is possible to just emulate their bug when we see it
> happening.

Unfortunately, neither is possible. The problem is when we are an
initiator, we already need to know if we are talking to a broken device
for the NATT payloads of the very first packet.

As a responder, we can detect it and exhibit the broken behaviour or
simply lie and omit the RFC payload so we use the draft. But
implementing that for just the responder is tricky, because the roles
could reverse and than we have intermittent connectivity issues.

So I decided we'll just have to use an option. My hope was that we could
tie this to an option we already have, cisco_unity=yes. Unfortunately,
that option causes more behavioural changes in the remote cisco. My
tunnel to the Red Hat Cisco does not establish when I set cisco_unity=yes.

So, we needed a new dedicated option for this. I've added

 	ikev1_nat=both|drafts|rfc

With "both" the default to match our current behaviour. IKEv2 NAT-T is
not affected by this option.

https://github.com/libreswan/libreswan/commit/ad3d582d31c47d44a48dccee2881147872a4ca23

Paul


More information about the Swan-dev mailing list