[Swan] Various problems with VTI on Gentoo (with Cisco IOS as a client)

Paul Wouters paul at nohats.ca
Mon Sep 19 15:44:45 UTC 2016

On Mon, 19 Sep 2016, Reuben Farrelly wrote:

> I've been experimenting today with Vti based configuration and run into a few 
> problems.

Thanks for testing the VTI support!

> 1. The first problem is when the IPSec completes negotiation.  As soon as the 
> IPsec connects up, I lose all IPv4 access to the remote box. This is made 
> even worse because the public route to the client is also wiped out, so the 
> IPsec session basically kills the connectivity to the box including that of 
> the IPsec session due to a recursive routing loop and more specific /1's for 
> the global routing table:
> lightning ~ # ip route
> dev vti01  scope link  src  mtu 1438
> default via dev eth0  metric 3
> dev lo  scope host
> via dev lo
> dev vti01  scope link  src  mtu 1438
> dev eth0  proto kernel  scope link  src
> lightning ~ #
> Even with:  vti-routing=no  I still see these routes appear, and experience 
> this problem.

That's odd. with vti-routing=no there should be no VTI specific routing

You seem to have the "half routes" 0/1 and 128/1 installed via the vti
device. Those are most certainly wrong, but I'm not sure why those were

> 2. What I would ideally like to do is have a tunnel interface on the Cisco, 
> and number it with  Ideally then on the Libreswan box I would 
> set which would give me a proper traditional numbered link.  I 
> only need connectivity across the directly connected subnet (don't want or 
> need any other routes to be reachable just yet - I'm NATting for this purpose 
> in the meantime).

Yes we are adding a leftvti= and rightvti= option to allow updown to
configure and ip address on the created vti device.

> The Cisco insists on as the src and dst proxy IDs for these sorts 
> of VTI connections on it's side.

It should work fine to set leftsubnet= and
rightsubnet= as long as you set mark="5" or some uniqu number.
The marking should prevent anything from being directed into the xfrm
path per default unless it was pointed to the VTI device.

> How would I configure Libreswan to work in this way?  [This would allow me to 
> match the config I have on the other IPsec Palo Alto head end, and 
> consistency is a great thing!]

Currently, just manually configure the IP address in updown?

> 3. I am seeing packets leave the Cisco across the Cisco Tunnel interface, and 
> I am seeing these packets enter the Libreswan vti. However every single one 
> of them is being dropped:
> lightning pluto # ifconfig vti01
> vti01: flags=193<UP,RUNNING,NOARP>  mtu 1428
>         tunnel   txqueuelen 1  (IPIP Tunnel)
>         RX packets 0  bytes 0 (0.0 B)
>         RX errors 5257  dropped 5257  overruns 0  frame 0
>         TX packets 2236  bytes 568568 (555.2 KiB)
>         TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
> lightning pluto #
> The TX packets were from me doing pings from the head end.  The Cisco never 
> sees any packets input but sees lots of packets output.
> Tested without iptables as well, so that isn't the issue.
> What would cause this?

Not sure. You can check /proc/net/xfrm_stat but I guess it would be
packets not within scope? Are you sure you configured a leftsubnet and
rightsubnet of 0/0 ?
Or did you not setup the IP on the vti interface and therefor have no
default route (as it is supposed to be over the tunnel) ?

> 4. Possibly related to (3) are these two tunnel types actually the same?
> 22: vti01 at NONE: <NOARP,UP,LOWER_UP> mtu 1428 qdisc noqueue state UNKNOWN mode 
> DEFAULT group default qlen 1
>     link/ipip brd

What does "ip tun" say?

> and on the Cisco:
> router-2#show int tun 1
> Tunnel1 is up, line protocol is up
>   Hardware is Tunnel
>   Description: Libreswan site-to-site IKEv2 VPN
>   Internet address is
>   MTU 17862 bytes, BW 256 Kbit/sec, DLY 50000 usec,
>      reliability 255/255, txload 1/255, rxload 1/255
>   Encapsulation TUNNEL, loopback not set
>   Keepalive not set
>   Tunnel linestate evaluation up
>   Tunnel source (Cellular0), destination
>    Tunnel Subblocks:
>       src-track:
>          Tunnel1 source tracking subblock associated with Cellular0
>          Set of tunnels with source Cellular0, 2 members (includes 
> iterators), on interface <OK>
>   Tunnel protocol/transport IPSEC/IP
> So one is IP/IP and the other is IPSEC/IP.  Is this expected?

I don't know how cisco shows that internally....

> The libreswan config looks like this:
> conn router-2.reub.net
>         left=
>         leftid=@lightning.reub.net
>         leftsubnet=
>         leftsourceip=
>         right=%any
>         rightid=router-2 at reub.net
>         rightsubnet=
>         authby=secret
>         ikev2=insist
>         ikelifetime=86400s
>         salifetime=3600s
>         ike=aes256-sha1;modp1536
>         phase2alg=aes128-sha1;modp1536
>         mtu=1438
>         dpddelay=15
>         dpdtimeout=45
>         dpdaction=clear
>         auto=add
>         mark=12/0xffffff
>         vti-interface=vti01
>         vti-routing=no
>         vti-shared=yes

Normally I'd say use vti-shared=no, but I guess that might require you
to have a static right= and not right=%any. You can temporarilly try it
with the known right ip address of the moment and see if that changes

> Child sa: local selector -
>           remote selector -

That looks fine.....

> Any advice would be appreciated.  I guess by using Cisco IOS and Gentoo Linux 
> I am not running an entirely standard combination of client+server but 
> nevertheless it would be good to be able to get this working, and to have 
> Gentoo be a working OS with VTI.

Well, it is precisely the interop with the big vpn vendors that we want
to learn about and make work. I don't think it matters much what linux
flavour you use, as long as the ip command is new enough to support
the VTI stuff.


More information about the Swan mailing list