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

[Philippe Vouters]

Dear Paul,

A Cisco IOS router available for testing is a scarce resource. I am 
blind copying on this mail two of my contacts I worked with on Cisco IOS 
issues, remotely connecting to their Cisco IOS router they offered me 
access to. I have to warn you : with one of my two contacts, the Cisco 
IOS router was borrowed from one of his clients. Thus the access to it 
was very time limited and hardly negotiated.

For the NAT-T payload, it happened, only in RSA mode, that with Cisco 
IOS Version 12.4(25d), the Cisco IOS router accepted NAT-T v03 but, to 
correctly set up the tunnel, one has to force NAT-T v02. Still in RSA 
mode and with Cisco IOS Version 1.4(4)M4, Cisco IOS accepted NAT-T RFC 
but, to correctly set up the tunnel, one has to force NAT-T v03 or NAT-T 
v02.

In PSK mode, this NAT-T issue was completely transparent whichever the 
Cisco IOS running version.

So my proposal to Libreswan developers is that instead of a simple 
nat_traversal={yes|no}, the choice for NAT-T is broaden mimicking what 
Shrew proposes the end-user as long as applicable.

For the NAT-T issue, the bug is indeed in Cisco IOS. However, Libreswan 
and Shrew weight nuts compared to Cisco. So Libreswan has to adapt to 
Cisco IOS like I did for Shrew.
--
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org

On 02/22/2014 04:38 PM, Paul Wouters wrote:
> On Fri, 21 Feb 2014, Philippe Vouters wrote:
>
>> I solved these specific two issues inside Shrew VPN client. The 
>> missing Libreswan sent issuer issue prevents any Libreswan use with 
>> Cisco IOS whichever the version. This missing Libreswan sent issuer 
>> issue leads to the symptom largely described at 
>> http://vouters.dyndns.org/tima/Linux-Windows-Cisco-VPN-Cisco_may_abort_when_attempting_to_establish_a_VPN.html 
>> that I strongly suggest you to carefully reread.
>
> That would require a cisco with the configuration for testing. And we
> would have to figure out the wire format used for sending the CAcert
> PLUS the EEcert.
>
>> The NAT-T issue symptom is described in the same document. Libreswan 
>> suffers from as was Shrew VPN Client until I modified it to allow the 
>> end-user to specify a force NAT-T v02 or V03 payload proposal 
>> preventing Shrew to propose a NAT-T RFC proposal. This was the only 
>> way with the two tested versions of Cisco IOS to have the tunnel 
>> correctly established.
>
> That one is easier to do. If all that Cisco needs is to _not_ see the 
> NATT
> vendorid to agree on the 02/02n/03 proposal. Does the cisco itself send
> the NATT RFC version? That is, do we also need to ignore the incoming
> RFC NATT payload?
>
> Paul
>