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

Paul Wouters paul at nohats.ca
Mon Feb 24 05:58:55 EET 2014


On Mon, 24 Feb 2014, Philippe Vouters wrote:

> 1/  Shrew seems to make a difference between NAT-T draft v02 and draft v03.
> With an indifferent code for the two, I fear Cisco/Libreswan users may not be
> able to correctly establish the tunnel with Cisco IOS at least version 12 or
> above and below version 15 or the contrary all depending whether your NAT-T
> draft implementation is v02 or v03.

Instead of speculating, I decided to check and look.  There is no
difference between draft 02 and 03 apart from the vendor ID:

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-ipsec-nat-t-ike-03.txt

I _think_ this was done because some vendors had adding a newline to the
vendor id in draft 02, and some had not. So with version 3 they clarified
that. This is why "02" and "02_n" exist as vendor id codes. So I believe
using nat_type=rfc|draft should be sufficient and much clearer than
confusing endusers with version numbers of drafts in option names. Perhaps
even use "default" and "old" instead of "rfc" and "draft".

> 2/ On a PC acting as a Web server such as my Linux Fedora 20 desktop,
> NetworkManager is indeed NOT an option at least for my network link.

Writing a python/glade or kde or gtk application might not be that
difficult. I currently do not have the resources to write one, although
I do have resources to test a gui application.

> 3/ You perhaps suppressed some outdated Openswan configuration options but
> how many did you add since ????

I'm intruiged by both your request for a NAT tweak option and the
request to reduce options. I am not sure what you want me to do. You are
both requesting I add an option and that I do not add options or even
remove options.

We could go through all keywords and see. But as you often emphasize
yourself, we should not break existing configurations. In fact, one of
the options I hope to get rid of soon is the "nexthop" option.

Each of those options is as important to someone else as the "nat_type"
option is to you.

> To backup this opinion, only remember the remote_peer_type=cisco

We have come a long way to remove that option in favour of clearer named
options that were not bundled under a single vendor name. I would like
to continue that work, but it is not at the top of my todo list right
now.

It's easy to point one or two use-cases. Libreswan (and openswan/freeswan)
has been supporting people since 1995. Please keep an open mind for other
people's issues as well. We make efforts to use sane default values so
users only have to specify very few mandatory options.

Paul


More information about the Swan-dev mailing list