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

[Philippe Vouters]

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.

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. On 
my wife's laptop, I even suppressed NetworkManager for her Wifi 
connection replacing it with wpa_supplicant. The problem on her laptop 
was that NetworkManager too easily triggered unwanted Wifi's, bringing 
her strong instability while Web browsing and causing me too much hard 
work to attempt to figure out why she could be complaining. Without a 
stable network link, it is totally useless to envision any 
NetworkManager provided VPN.

3/ You perhaps suppressed some outdated Openswan configuration options 
but how many did you add since ???? I can say Openswan was already not 
user-friendly at all. Lots of hazards was already left onto the non 
Openswan deep specialist. And these non Openswan specialists could be 
recruited in ipsec VPN experts. Only remember someone like Elison Niven 
and the nature of the questions he asked the Libreswan mailing list. He 
was very VPN experienced but not enough skilled in the internals of 
Openswan/Librewswan. This internals knowledge appeared since long and 
still appears to me as a MUST when one tries to make the link between a 
pluto configuration and a pluto log. To backup this opinion, only 
remember the remote_peer_type=cisco issue faced by Miroslav Beetak and 
the right=%any issue I personally faced. The technical aspect of these 
two issues is respectively described at:
http://vouters.dyndns.org/tima/Linux-Libreswan-remote_peer_type_option.html
http://vouters.dyndns.org/tima/All-OS-VPN-One_reason_why_VPN_can_be_so_delicate_to_correctly_configure.html


Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

On 02/24/2014 03:44 AM, Paul Wouters wrote:
> On Sun, 23 Feb 2014, Philippe Vouters wrote:
>
>> For NAT-T along with my changes (NAT-T v02 and v03), Shrew's qikea 
>> now proposes in one pull-down menu: {disable | enable | force-draft | 
>> force-natv02 | force-natv03 | force-rfc | force-cisco-udp }. I do not 
>> know whether the Shrew code owner wouldn't like to rename 
>> force-nat{v02 | v03} (my work) to force-{v02 | v03} as this pull-down 
>> menu is specific to a 'Nat Traversal' configuration.
>
> We could introduce nat_type=rfc|draft (default rfc) where draft is 02/03
> (there is no functional difference in our code)
>
>> If there is an intent to render the end-user task even more complex 
>> by always adding new options to ipsec configurations, perhaps it 
>> would be time to design a GUI tool
>
> There is NetworkManager-openswan that has been ported to libreswan and
> could be extended to include more options. We are not planning on
> writing a gui application from scratch.
>
>> This would make Libreswan more user-friendly which it becomes less 
>> and less over releases.
>
> I don't agree with this opinion. We have in fact _removed_ various
> obsoleted options to pluto and keywords in ipsec.conf in the last few
> releases. While the options still get parsed and ignored in the code,
> the user never needs to know about those options anymore. While we prefer
> fewer options over more options, we do deal with a lot of 
> interoperability
> issues, such as this natt Cisco case, that adds options for the user.
>
> In some recent cases, we had #ifdef code to interop with broken VPN
> software from 10+ years ago. Instead of turning those #ifdef's into new
> options, we choose to just no longer support those pre-Windows XP
> software clients anymore.
>
> If you know of any other simplifications we should do regarding the
> supported options, let us know and we can discuss the value of those
> options.
>
> Paul
>