[strongSwan] local_ts based on user/group

[Christian Salway]

Thanks, Tobias,

I went down the route of writing a custom updown script as I didn’t know how to write hooks so this seemed easiest.

cat <<EOF > /opt/strongswan/_updown
#!/bin/bash

LDAPURL='${LDAPURL}'
BASEOU='${BASEOU}'
BINDUN='${BINDUN}'
BINDPW='${BINDPW}'

TAG=charon-route
FAC_PRIO=local0.notice

IPSEC_POLICY="-m policy --pol ipsec --proto \$PLUTO_PROTO --reqid \$PLUTO_REQID"
IPSEC_POLICY_IN="\$IPSEC_POLICY --dir in"
IPSEC_POLICY_OUT="\$IPSEC_POLICY --dir out"

case "\$PLUTO_VERB" in
up-client)
    # expects a group name in the format cidr-xx.xx.xx.xx-nn, eg: cidr-172.31.0.0-16
    ldapsearch -H "\${LDAPURL}" -x -D "\${BINDUN}" -w "\${BINDPW}" -b "\${BASEOU}" -LLL "(sAMAccountName=\${PLUTO_XAUTH_ID})" memberOf | \\
        grep -oP '(?<=memberOf: CN=cidr-).+?(?=,OU.+)' | \\
        sed 's|-|/|' | while read CIDR
    do
        iptables -I FORWARD 1 -o \$PLUTO_INTERFACE -p \$PLUTO_PEER_PROTOCOL \\
            -s \$CIDR -d \$PLUTO_PEER_CLIENT \$IPSEC_POLICY_OUT -j ACCEPT

        iptables -I FORWARD 1 -i \$PLUTO_INTERFACE -p \$PLUTO_MY_PROTOCOL \\
            -s \$PLUTO_PEER_CLIENT -d \$CIDR \$IPSEC_POLICY_IN -j ACCEPT

        logger -t \$TAG -p \$FAC_PRIO \\
            "+ \$PLUTO_XAUTH_ID (\$PLUTO_REQID) \$PLUTO_PEER_CLIENT == \$PLUTO_PEER -- \$PLUTO_ME == \$CIDR"
    done
    ;;
down-client)
    # remove rules - yet to be written. Needs to assume the user might have been removed from the Group before disconnection
    iptables -F FORWARD  # TESTING ONLY
    ;;
*)  echo "\$0: unknown verb '\$PLUTO_VERB'" >&2
    ;;
esac
EOF
chmod +x /opt/strongswan/_updown



children {
    child {
        local_ts = ${CLIENT_ROUTES}
        updown = /opt/strongswan/_updown
    }
}


> On 31 Oct 2019, at 09:22, Tobias Brunner <tobias at strongswan.org> wrote:
> 
> Hi Christian,
> 
>> How would that work? Because a user can be a member of one or more groups and thus how does strongswan select the connection with all the groups.
> 
> Since a single group match is currently enough to satisfy the group
> constraint (there is also no "best"-match based on groups), you'll have
> to assign unique groups to the users that have access to specific
> networks.  That is, groups for individual networks won't work (unless
> members of such groups only have access to one network), you need groups
> that allow access to combinations of networks.  If you can't change the
> original group assignment, you'll need to map them somehow, for
> instance, write a plugin that implements the authorize hook and assign a
> new group based on the ones already assigned.  Alternatively, write a
> plugin that implements the narrow hook and assigns traffic selectors
> based on whatever strategy you like.
> 
> Regards,
> Tobias

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20191031/8a85a28c/attachment-0001.html>