On Thu, 3 Dec 2015, Paul Wouters wrote:
> > - 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?
Marking is indeed useful here to ensure that default packets are not matching
the policy, which was my initial problem.
In my updown, instead of marking packets with mangle, I still use my old
approach of setting narrower policies:
--
Updown script:
# We want to route LOCAL_IP <-> any, not any <-> any, through the tunnel
LOCAL_IP=10.246.89.31
# Update the SPD to use <local-ip>/ <-> /any through the tunnel
function set_specific_rules() {
log "Adding specific-ip-to-any SPD entries..."
ip xfrm policy add src $LOCAL_IP/32 dst 0.0.0.0/0 dir out tmpl src
$PLUTO_ME dst $PLUTO_PEER proto esp reqid $PLUTO_SA_REQID mode tunnel priority
2000
log "Adding dir out result: $?"
ip xfrm policy add dst $LOCAL_IP/32 src 0.0.0.0/0 dir in tmpl dst
$PLUTO_ME src $PLUTO_PEER proto esp reqid $PLUTO_SA_REQID mode tunnel priority
2000
log "Adding dir in result: $?"
ip xfrm policy add dst $LOCAL_IP/32 src 0.0.0.0/0 dir fwd tmpl dst
$PLUTO_ME src $PLUTO_PEER proto esp reqid $PLUTO_SA_REQID mode tunnel priority
2000
log "Adding dir fwd result: $?"
}
function unset_specific_rules() {
log "Removing customized specific-ip-to-any SPD entries..."
ip xfrm policy del src $LOCAL_IP/32 dst 0.0.0.0/0 dir out
log "Removal for dir out result: $?"
ip xfrm policy del src 0.0.0.0/0 dst $LOCAL_IP/32 dir in
log "Removal for dir in result: $?"
ip xfrm policy del src 0.0.0.0/0 dst $LOCAL_IP/32 dir fwd
log "Removal for dir fwd result: $?"
}
# This script is called with a verb:
# up-client, then prepare-client, then route-client.
# Based on tests, even on up-client netkeys rules are set already (i.e. SPD
updated).
# However because this looks prettier, we will update the rules in route-client
only.
case $PLUTO_VERB in
route-client)
set_specific_rules
;;
unroute-client)
unset_specific_rules
;;
*)
log "$0 called with verb $PLUTO_VERB"
;;
Esac
--
As a matter of fact, I don't need to set these rules in a updown script, they
could have been set once for all outside a connection.
However "ipsec (re)start" resets all set policies, so that's still a convenient
place to do it.
> could you share how you actually are ensuring the right packets go into the
> right tunnels if you dont use iptables mangling in updown?
See above.
In our VPN concentrator model, we expose a single private IP address specific
to each tunnel. So based on this specific IP, we can select the tunnel to use.
This approach does not block packets if the VPN is not up (they'll be routed
through the default gateway), so this is still far from perfect.
Thanks,
-seb
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
