[Swan-dev] Did Libreswan address these two issues with a Cisco IOS peer ??????

[Paul Wouters]

On Mon, 24 Feb 2014, Philippe Vouters wrote:

> Correct me if I am wrong. You would really fear to break existing so your 
> tendency would be to always add.
>
> Instead of adding a new nat option per conn, a suggestion I make which seems 
> reasonable is that you simply pluto code ignore nat_traversal={no | yes } at 
> global ipsec.conf level and you pluto code enable nat_traversal defaulting to 
> yes at conn level along with your no and the other explicit options such as 
> Shrew proposes in its NAT Traversal qikea pull-down menu.

I had already removed the global option, it is ignored now:

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

It might a good idea to use the same option name for the per-connection
setting though. nat_traversal=yes|draft|no. But using a new name also
has an advantage of not conflicting with old documentation a user might
find online.

The values "no" and "draft" are not valid options for IKEv2. And
connections can be configured with ikev2=yes|permit which means a
connection could become either ikev1 or ikev2. We could ignore
nat_traversal= completely when using IKEv2.

Except we _do_ disable nat_traversal if the kernel does not support it,
which only happens for 2.4 kernels that use KLIPS without the NAT-T
patch.

> As far as I could observe from a NAT'ed and a non NAT'ed actual VPN runtime 
> configuration, setting systematically nat_traversal=yes is automatically 
> detected by both Shrew and Libreswan which runtime turn NAT off when non 
> NAT'ed.

Yes, ESP in UDP encapsulation is negotiated with IKE. When no NAT is
detected, encapsulation is not done.

> Such scheme would prevent a new option and would keep enough clarity in the 
> ipsec.conf man for the end-user mind by not distracting him with the same 
> concern through different pluto options.

Moving an option from the global to the per-connection section is really
a new option with the same name. One could argue the user could be more
confused by an option of the same name, as googling and finding old
postings about putting it in the global section would be misinforming
the user, while a new option name would not cause such confusion.

So I'm a little conflicted still if we should re-use the old name, or
use a new name. What do other people think?

> By the way, with Cisco IOS, PSK implies Aggressive mode; RSA implies Main 
> mode.

Not always. Cisco can do PSK with Main Mode as well. Perhaps the GUI
does not allow it, but the CLI does allow it. At least in some Cisco's
I have seen.

> For the NAT-T v02 versus v03, I saw it does make a runtime difference with 
> Shrew and a Cisco peer. I have to hard dig into Shrew code to pinpoint the 
> actual code difference between the two drafts implementation.

Please let me know if you see a difference in code.

Paul