[Swan] Cisco IOS XE Interoperability with Libreswan

[Reuben Farrelly]

On 18/08/2018 2:15 PM, Reuben Farrelly wrote:
> On 18/08/2018 3:25 am, Paul Wouters wrote:
>> On Sat, 18 Aug 2018, Reuben Farrelly wrote:
>>
>>> I'm now testing with another router running classic IOS (not-XE) and 
>>> it is also seeing some problems establishing an IPSec session.  This 
>>> router is running the latest released version of classic IOS (15.8(3)M).
>>
>>> The IOS XE router won't connect to any versions at all.
>>>
>>> I've posted the debugs for both classic IOS sessions up online for 
>>> comparison:
>>>
>>> http://www.reub.net/files/libreswan/Libreswan-3.22-working.txt
>>> and
>>> http://www.reub.net/files/libreswan/Libreswan-3.25-NOT-working.txt
>>
>> The non-working one and the working one both setup an IPsec SA for 0/0
>> to 0/0 according to the logs using the same IKE and ESP parameters.
>>
>> The non-working one immediately receives an additional INFORMATIONAL
>> exchange message with a ISAKMP_NEXT_v2CP Configuration Payload as
>> defined in https://tools.ietf.org/html/rfc7296#section-3.15
>>
>> It seems the Informational exchange can contain a CP payload, although
>> we surely aren't expecting this to happen:
>>
>> https://tools.ietf.org/html/rfc7296#section-1.4
>>
>> So we treat the informational as a DPD type and just reply with an
>> empty informational exchange packet. Then we receive another
>> informational but now a real empty one, so a real DPD one and we
>> reply. All seems well. Nothing in the logs you post indicate a problem,
>> or show that the tunnel is "not working".
> 
> It's definitely not working with 3.25 but always works with the 3.22, 
> and is 100% reproducible.
> 
> My test case is a single /30 between the router and Libreswan, and I'm 
> attempting to ping across it.  In other words no routing required as the 
> two ends are on the same IP subnet.
> 
> Configs:
> 
> conn router-2.reub.net-ipv4
>          left=110.232.112.209
>          leftid=@lightning.reub.net
>          leftsubnet=0.0.0.0/0
>          right=%any
>          rightid=router-2 at reub.net
>          rightsubnet=0.0.0.0/0
>          authby=secret
>          ikev2=insist
>          ikelifetime=86400s
>          salifetime=3600s
>          # IOS XE
>          #ike=aes-sha2_512;dh19
>          # Classic IOS
>          ike=aes-sha2_512;dh5
>          dpddelay=15
>          dpdtimeout=45
>          dpdaction=clear
>          auto=add
>          mark=-1/0xffffffff
>          vti-interface=vti-1
>          leftvti=192.168.6.1/30

Ok I've worked out the cause of this.  The problem is the 'mark' value 
that I have configured.

According to the man page:

====

If set, the MARK to set for the IPsec SA of this connection. The format 
of a CONNMARK is mark/mask. If the mask is left out, a default mask of 
0xffffffff is used. A mark value of -1 means to assign a new global 
unique mark number for each instance of the connection. Global marks 
start at 1001. This option is only available on linux NETKEY/XFRM 
kernels. It can be used with iptables to create custom iptables rules 
using CONNMARK. It can also be used with Virtual Tunnel Interfaces 
("VTI") to direct marked traffic to specific vtiXX devices.

====

Up to and including version 3.23 this worked (or at least it didn't 
break anything).

 >          mark=-1/0xffffffff

In version 3.25 the use of -1 here seems to have broken things.

After setting the mark (statically) to '1' instead of '-1' I have 
connectivity again across the IPSec tunnel.
I think that's a bug either in the man page, or in the code ;-)

Now that the cause of that has been determined, I can get back to 
testing my IOS XE router.

Reuben