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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
