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

Sébastien Lefevre sebastien.lefevre at homesend.com
Wed Dec 2 09:26:41 UTC 2015


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.

I'm focusing my tests on IKEv1, though a similar problem occurs on IKEv2.

My connection:
conn ciscovti
  type=passthrough
  left=myendpoint
  # this is my "target" leftsubnet I would like to route through this tunnel
#  leftsubnet=10.246.89.31/255.255.255.255
  # But this is what I need to set for IKE proposals to be accepted on both sides
  leftsubnet=0.0.0.0/0
  right=ciscoendpoint
  rightsubnet=0.0.0.0/0
  ike=aes256-sha1
  phase2=esp
  pfs=no
  phase2alg=aes192-sha
  authby=secret
  # This connection is started manually as it can break the routing
  auto=ignore
  ikelifetime=8h
  salifetime=1h
  remote_peer_type=cisco
  # Lowest priority possible - because we set a policy any-to-any without tunnel at prio 60000
  priority=65535
  leftupdown="/root/updown.sh"
  # I tried a dpdaction=restart to see if in that case the updown script was called on SA nego, bu this is not the case apparently
  dpdaction=restart
  dpddelay=30
  dpdtimeout=120
  # Forced reqid so that we can control SA/SPD entries policies manually including in case of a SA refresh
  reqid=16000


My understanding of the problem:

(1) Upon successful IKE phase 1 negotiation (or is that phase 2?), libreswan sets netkey policies matching the configured and accepted leftsubnet/rightsubnet:

ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 priority 65535 dir in tmpl src myendpoint dst ciscoendpoint mode tunnel proto esp reqid 16000.
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 priority 65535 dir out tmpl dst myendpoint src ciscoendpoint mode tunnel proto esp reqid 16000.
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 priority 65535 dir fwd tmpl dst myendpoint src ciscoendpoint mode tunnel proto esp reqid 16000.

As soon as these rules are set, I lose the connectivity to my VPN concentrator, unless I set, prior to the negotiation (i.e. before ipsec auto --add ciscovti for instance), "masking" policy rules such as:

ip xfrm policy add src 0.0.0.0/1 dst 0.0.0.0/1 priority 60000 dir {in,out,fwd} 
ip xfrm policy add src 128.0.0.0/1 dst 128.0.0.0/1 priority 60000 dir {in,out,fwd} 

(using split networks because rules matching 0.0.0.0/0 directly collide with the ones installed by libreswan and are replaced)

If these rules are set, then I can still get maintain a ssh connectivity to my VPN concentrator. However, at this stage, external traffic that is supposed to be forwarded by my concentrator, including the one coming from other tunnels terminated on the concentrator, is routed through this Cisco tunnel (?!).

(2) Several seconds after, librewan calls my custom updown script.

(3) In this custom updown.sh scripts, on route-client, I remove the 0.0.0.0/0 rules added in (1) and add some narrower rules to select the actual traffic to route through this tunnel. This works pretty well and from then only selected traffic is routed through this tunnel.

(4) However at the next SA negotiation (i.e. every hour), libreswan re-install a policy that seems to be:
ip xfrm policy add src 0.0.0.0/0 dst 0.0.0.0/0 priority 65535 dir out tmpl dst myendpoint src ciscoendpoint mode tunnel proto esp reqid 16000

And this time my updown.sh script is not called. So after 1h, incoming forwardable traffic is forwarded through this cisco tunnel again. So unless I poll for this policy change and delete it as soon as I detect it, the concentrator is basically broken.


So, my questions:

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

Thank you very much,

-seb



More information about the Swan mailing list