[Swan] Interworking with Cisco VTI model (any-to-any tunnel, selected routing)

Sébastien Lefevre sebastien.lefevre at homesend.com
Thu Dec 3 14:55:42 UTC 2015

Hi Paul,

Thanks for all of this, it worked perfectly.

On Wed, 2 Dec 2015, Paul Wouters wrote:
> On Wed, 2 Dec 2015, Sébastien Lefevre wrote:
> > Hello everybody,
> >
> > I'm having some trouble trying to configure a vpn against a Cisco ASA
> appliance that is using the Cisco Virtual Tunnel Interface (VTI) configuration
> style, which is apparently the recommended configuration model for Cisco
> for some years now.
> > The problem is that, in this mode, the Cisco endpoint only advertises "any-
> to-any" in its traffic selectors (IKEv2) or equivalent payloads in IKEv1, and
> won't accept a libreswan-emitted proposal that does not contain these
> <-> traffic selectors either.
> > On libreswan side, it won't accept Cisco proposals until I configure my
> leftsubnet to as well as rightsubnet to
> > Of course, in that case, the whole traffic is routed to this Cisco endpoint,
> which is not acceptable, as I'm using libreswan as a VPN concentrator, also
> connected to other VPNs (other Cisco in older crypto-map style or other
> libre/open/strongswan and racoon implementations).
> >
> > We're using the libreswan version of our distrib (CentOS7) whose kernel
> does not support KLIPS by default, so I'm currently stuck with NETKEY.
> That is what is called a "routed based VPN" (versus a "policy based
> VPN"). It is, in my very opiniated view, a lazy and insecure way of
> setting up VPNs.

I have the feeling that Cisco is pushing this approach for scalability and performance reasons: they are better at manipulating large routing tables than SPD entries or SAs, so it's simpler for them to implement a single policy any-to-any. But anyway, this might be off topic, so sorry.

> > (a) Is there a recommended approach to deal with this Cisco VTI model?
> According to our partner operating this Cisco endpoint, this is a widely used
> configuration. I might have missed something as I couldn't find a lot of posts
> relating a problem with it.
> > (b) Is there a way to completely disable policy management done by
> libreswan, making it focus on SA/keys negotiations only? (I tried
> mode=passthrough but policies are still set by it)
> While we just added support for marking, which could help you a bit, we
> are still working on properly supporting Linux VTI. I envision that in
> the case of VTI, we would setup the above policy, but only that what is
> routed into the ip_vtiXX device, would actually get into the IPsec SA.
> If you use marking (grab the libreswan git master from github), you can
> select a mark number and then only mark the traffic with the right
> source/dest you really want to send over the tunnel. We should probably
> add a new option for that to list a comma seperated list of CIDRs that
> would automatically get MARKed for you if set.

That's a good idea indeed to simplify some setups.

> the marking iptables rules also need the reqid, so easiest is if you
> add to your conn:
>  	mark=7
>  	reqid=7

Small remarks here:
- The connection's mark parameter expects a string, so this is mark="7" to make it work. I don't know if this is on purpose. 
- That was enough to make my workaround based on a updown script work: it can safely set policies without involving mangling/marking, the any-to-any policies set by libreswan being just unused and not matching any packets anymore. That's much less elegant than the complete solution you proposed, but it works.
- When stopping the tunnel via an "ipsec auto --delete/down conn", the dir out policy remains in place and is not automatically removed by libreswan, while the dir in and dir fwd are (got a ERROR: netlink XFRM_MSG_DELPOLICY response for flow eroute_connection delete included errno 2: No such file or directory, but only on --delete).

> then run something like this (assuming you only wanted to give the
> remote Cisco the traffic of
> MARK=7
> iptables -t mangle -A PREROUTING -i eth0 -s -m policy --dir in
> --reqid $REQID -j MARK --set-xmark $MARK
> iptables -t mangle -A PREROUTING -i eth0 -s  -m policy --dir in
> --reqid $REQID -j CONNMARK --save-mark

I tried this approach instead of setting explicit policies, but didn't manage to get it work, probably due to my poor knowledge of iptables and mangle/nat interactions ( is the published source IP for SNATted systems SNATed on the host running libreswan).
Anyway, the initial problem has now a solution and we can connect to multiple Cisco VTI-based tunnels if needed. Thank you!


More information about the Swan mailing list