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

[Philippe Vouters]

Dear Paul,

As a guidance for you and as a first step for the missing issuer issue, 
you may download http://vouters.dyndns.org/zip/ike-2.2.3.diff.tar.gz and 
watch at the changes I brought to Shrew 2.2.1-release. The points of 
interest when editing this .diff file are when searching after the 
"issuer" string occurrences. The solution does not show up the exact 
same way with Libreswan.

Yours truly,

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
>