Strongswan clients access rights

Question

I am beginner with strongswan so I apologize for this beginner’s query. I have created Debian server with strongswan. To this server are connected three networks network_1: 192.168.10.0/24, network_2: 192.168.20.0/24 and network_3 192.168.30.0/24 via Mikrotik LTE routers and IKEv2-PSK protocol. Together with these network to this server can be connected windows, iOS, OSX and Android clients via IKEv2 protocol and MSCHAP-EAP authentication. All is working without problems and for every connected client are accessible all IPs in all these three networks.

At this moment I would like assign some of the following access rights for MSCHAP-EAP clients – for example:

Client Bob/password1 should be able to access only IPs in network2 and no other IPs Client Alice/password2 should be able to access only IP address range 192.168.20.100 – 150 in second network and no other IPs Client John/password3 should be able to acces only IP address ranges 192.168.30.10 – 50 and 192.168.10.150 -200 and IP address 192.168.20.44

Could anybody be so kind and help me solve it? Ideally with reference to any example of solution…

Thank you in advance

Petr

score 4 · Accepted Answer · answered Apr 18 '18 at 08:48

A possible way to do this is using EAP-RADIUS. The radius server can return Class attributes that can be matched against configs (rightgroups in ipsec.conf, or groups in swanctl.conf). Then you can define different local traffic selectors for each of these groups. The ikev2/rw-eap-md5-class-radius strongSwan test scenario illustrates this.

If you don't want to or can't use EAP-RADIUS there is a way to match individual EAP identities but it's a bit tricky because strongSwan does not fully support connection switching based on such identities. To do this a dummy connection with a fake group has to be used. This is how it could look like in ipsec.conf:

conn eap-shared
   # options shared by all clients e.g.
   leftcert=...
   # or
   rightsourceip=...
   # or
   rightauth=eap-mschapv2

conn eap-init
   also=eap-shared
   # this config is used to do the EAP-Identity exchange and the
   # authentication of client and server
   eap_identity=%identity
   # the following is used to force a connection switch after
   # the authentication completed
   rightgroups=<any string that is not used as group/class>
   auto=add

conn eap-bob
   also=eap-shared
   eap_identity=bob@strongswan.org
   # any options that only apply to this user follow here e.g.
   leftsubnet=192.168.20.0/24
   auto=add

conn eap-alice
   also=eap-shared
   eap_identity=alice@strongswan.org
   # any options that only apply to this user follow here e.g.
   # (note that ipsec.conf does not support ranges, and most kernel
   #  interfaces do neither, so a range might be converted to a larger
   #  subnet when installing IPsec policies, so deaggregating the range
   #  is the most accurate way to do this currently)
   leftsubnet=192.168.20.100/30,192.168.20.104/29,192.168.20.112/28,192.168.20.128/28,192.168.20.144/30,192.168.20.148/31,192.168.20.150/32
   auto=add

conn eap-john
   also=eap-shared
   eap_identity=john@strongswan.org
   # any options that only apply to this user follow here e.g.
   # (see above)
   leftsubnet=192.168.30.10/31,192.168.30.12/30,192.168.30.16/28,192.168.30.32/28,192.168.30.48/31,192.168.30.50/32,192.168.10.150/31,192.168.10.152/29,192.168.10.160/27,192.168.10.192/29,192.168.10.200/32,192.168.20.44/32
   auto=add

With EAP-RADIUS the config would look quite similarly but you wouldn't need the eap-init connection (instead you'd add eap_identity=%identity to eap-shared) and instead of defining eap_identity in each individual connection you'd set rightgroups to the groups (i.e. EAP-RADIUS Class attribute values) for which that connection should be used (i.e. this allows using the same conn section for multiple users).

This works and works well, but I'm _fascinated_ to know how you worked out how to do this, since the only docs I can find about right groups indicate that it is for use with eap-radius only. If you could explain the logic, or better still link to docs, I would be grateful? — Philip Adler, Nov 14 '20 at 11:49
While the "group" feature is mainly used by the _eap-radius_ plugin, there are others that set it. For instance, the _eap-tnc_ plugin uses it to apply policies to clients depending on their measurements, and the _acert_ plugin applies groups from attribute certificates. The point is that if the config requires a group, but no group has been applied to a client by any plugins, the config won't match and has to be switched. So by applying a random group to the first conn, it'll fail after the EAP-Identity exchange and another conn is searched, which also must match the returned EAP-Identity. — ecdsa, Nov 16 '20 at 09:29
In Debian, need to install plugin `eap-radius` available in package `libcharon-extra-plugins` too. — Chau Chee Yang, Jul 22 '21 at 07:08
The connection sequence register at runtime is important too. Use `swanctl --list-conns` to show the connections sequence. Make sure `eap-init` always on top. — Chau Chee Yang, Jul 22 '21 at 07:10

score 0 · Answer 2 · answered Nov 10 '20 at 10:05

The accepted answer mostly worked for us, with a minor change. We use

conn    %default
    # Settings for all conn to inherit
    # But we included this in our settings:
    auto=add

As a result the above accepted answer "conn eap-shared" inherited "auto=add" which breaks this. The default "auto=" for ipsec.conf is "auto=ignore" so unless you have set this, the default is used.

One fix would be to remove "auto=add" from "conn %default" and then it becomes the default, another is to change it to "auto=ignore", but yet another is to change the "conn eap-shared" to explicitly include "auto=ignore" and nothing else, inheriting all of the "conn %default" settings. Then in "conn eap-init" add "auto=add" and for each connection after, with "also=eap-shared" also add a line "auto=add"

It is pretty unlikely for anyone to need this and have set "auto=add" in a "conn %default" but if you do, I hope this helps you.

Thanks @ecdsa ( https://serverfault.com/users/95913/ecdsa ) for your answer; It worked for me without having to run RADIUS or other services and now windows users can save their VPN password.

Copy-pasting your solution with the changes we had:

conn %default
    # All options shared on all connections, including
    auto=add

conn eap-shared
    # Because 'conn %default' has all settings shared between all conn, just:
    auto=ignore

#And the rest is as-is, since the original already has 'auto=add' in each conn:

conn eap-init
   also=eap-shared
   # this config is used to do the EAP-Identity exchange and the
   # authentication of client and server
   eap_identity=%identity
   # the following is used to force a connection switch after
   # the authentication completed
   rightgroups=<any string that is not used as group/class>
   auto=add

conn eap-bob
   also=eap-shared
   eap_identity=bob@strongswan.org
   # any options that only apply to this user follow here e.g.
   leftsubnet=192.168.20.0/24
   auto=add

conn eap-alice
   also=eap-shared
   eap_identity=alice@strongswan.org
   # any options that only apply to this user follow here e.g.
   # (note that ipsec.conf does not support ranges, and most kernel
   #  interfaces do neither, so a range might be converted to a larger
   #  subnet when installing IPsec policies, so deaggregating the range
   #  is the most accurate way to do this currently)
   leftsubnet=192.168.20.100/30,192.168.20.104/29,192.168.20.112/28,192.168.20.128/28,192.168.20.144/30,192.168.20.148/31,192.168.20.150/32
   auto=add

conn eap-john
   also=eap-shared
   eap_identity=john@strongswan.org
   # any options that only apply to this user follow here e.g.
   # (see above)
   leftsubnet=192.168.30.10/31,192.168.30.12/30,192.168.30.16/28,192.168.30.32/28,192.168.30.48/31,192.168.30.50/32,192.168.10.150/31,192.168.10.152/29,192.168.10.160/27,192.168.10.192/29,192.168.10.200/32,192.168.20.44/32
   auto=add

Thanks again @ecdsa ( https://serverfault.com/users/95913/ecdsa )

score 0 · Answer 3 · answered Apr 18 '18 at 17:26

0

Thank you very much for your answer. I will test it. My first idea was change the mschap-eap authentication to eap-tls and use different client's certificates and conn section for each group but I don't know if it would be the right way.

answered Apr 18 '18 at 17:26

Petr W.

23
8

Sorry, didn't see this before. Did you mean to add this as a comment to my answer? Anyway, EAP-TLS wouldn't make much of a difference as there again is the problem that switching based on EAP identities isn't fully supported (and different client implementations may use different forms of EAP identities when using certificates). Using plain certificate authentication may be an alternative as that allows matching configs via subject DN (even with wildcards), however, the identities sent might still depend on the client (some send the full subject DN, others the CN, or a SAN). – ecdsa Apr 20 '18 at 11:31
Hm, my idea with certificates was not good. I'll have to solve it with RADIUS server. – Petr W. Apr 23 '18 at 14:27
ecdsa, thank you very much for your help once more. Strongswan server is now working together with FreeRADIUS + MySQL without problems and a lot of users in usergroups that have access rights via EAP-MSCHAP to the appropriate ranges in appropriate networks:-) – Petr W. May 05 '18 at 19:25

Strongswan clients access rights

3 Answers3

Linked