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