[Swan] Interworking with Cisco VTI model (any-to-any tunnel, selected routing)

Sébastien Lefevre sebastien.lefevre at homesend.com
Thu Dec 3 16:21:55 UTC 2015


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


More information about the Swan mailing list