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

[Paul Wouters]

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 0.0.0.0/0 <-> 0.0.0.0/0 traffic selectors either.
> On libreswan side, it won't accept Cisco proposals until I configure my leftsubnet to 0.0.0.0/0 as well as rightsubnet to 0.0.0.0/0.
> 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.

> (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.

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

 	mark=7
 	reqid=7

then run something like this (assuming you only wanted to give the
remote Cisco the traffic of 10.246.89.31/32):


MARK=7
REQID=7
iptables -t mangle -A PREROUTING -i eth0 -s 10.246.89.31/32 -m policy --dir in --reqid $REQID -j MARK --set-xmark $MARK
iptables -t mangle -A PREROUTING -i eth0 -s 10.246.89.31/32  -m policy --dir in --reqid $REQID -j CONNMARK --save-mark

Paul
ps. we just found a bug - you might need to use REQID=6  (eg -1)