[strongSwan] local_ts based on user/group

[Christian Salway]

... for completeness, this is the down-client script

down-client)
    iptables -S FORWARD | grep "reqid \${PLUTO_REQID}" | cut -d' ' -f2- | while read RULE
    do
        iptables -D \$RULE

        logger -t \$TAG -p \$FAC_PRIO -- \\
            "- \$PLUTO_XAUTH_ID (\$PLUTO_REQID) \$RULE"
    done
    ;;


> On 31 Oct 2019, at 22:56, Christian Salway <christian.salway at naimuri.com> wrote:
> 
> 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 <mailto: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/8f3104c9/attachment.html>