On Thu, 3 Dec 2015, Sébastien Lefevre wrote:
Thanks for all of this, it worked perfectly.
Awesome!
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.
Yes. We will not put that in the 3.16 release yet but surely it will go
into 3.17.
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's an odd bug in the parser it seems. The type value of mark is
kt_string because it also accepts a mask, eg: mark=7/0xffffffff. But
if you only put in a number, for some reason it does not think that is
valid text. Maybe Hugh (CC: added) can share some light on that?
- 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.
I guess since you "hardcode" the network ranges, you didn't need to use
marking right? You just used marking to ensure all default unmarked
packets would not hit the policy? But you must have marked something
in updown to make it match the policy?
- 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).
Ahh, we might not have added the mark bits to the delete command. We'll
look at fixing that before 3.15.
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!
could you share how you actually are ensuring the right packets go into
the right tunnels if you dont use iptables mangling in updown?
Paul
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
