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 > 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. 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 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 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 (10.246.89.31/32 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! Cheers, -seb _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
