Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Rant - SSLVPN with Duo RADIUS Proxy Change after SFOS 20.0.0

So, I wanted to post a bit of a rant here regarding an undocumented change to RADIUS authentication after SFOS 20.0.0 that has broken my DUO MFA implementation.

For years I have had my users added from AD and I was able to pull multiple groups through this connection.  I use this for many things like differentiating staff and student internet access as well as VPN access to several different systems.  For example one group gives users remote access to file servers so they can access file servers remotely, while another group gives access to a VPN profile that gives them access to our HVAC system (they need this even when on-site).  Authentication happed using RADIUS which went through a DUO proxy server so that they would get a push notification to the DUO client whenever they connected the VPN.  Setup works great.  Duo Proxy was set up to query AD server for username/password verification using AD client and reply back to Sophos using RADIUS with no NPS server involved.

Here is the rant part.  After 20.0.0 my firewall now looks for a filter-id to be included with the radius lookup.  So, now I add the user via AD and I can see all the groups in Authentication->Users on the firewall.  When the use tries to connect to the VPN the firewall wipes those group memberships and looks for Filter-ID to set the group memberships.  Being that I never used filter-id previously it resets the users group to "Open Group" and refuses to allow them to log in.  I opened a ticket with Sophos to get this change rolled back or fixed and they said that I need to set up a NPS server and use that to pass through the filter-id and change my Duo proxy to RADIUS client instead of AD client.  My problem with this is that filter-id only supports one value per network policy.  I am currently using up to 6 different groups per user.  This small change on their system is adding complication to my setup that I did not want to deal with at the moment.



Edited TAGs
[edited by: Erick Jan at 12:37 AM (GMT -7) on 25 Oct 2024]
Parents
  • In v20MR1 we have fixed one Radius group membership issue listed below: 

    NC-127830

    Authentication

    RADIUS users who aren't part of VPN group are able to connect to SSL VPN.


    Prior to this fix
    : In scenario where user is part of  multiple groups and all groups are available in SFOS too. User group will be mapped to “Group and Other group memberships”.

    Now in case all the groups are removed from this user on Radius, in this case user’s “Group” value use to retain and hence user was able to access resources as per last group policy.

    Fix in v20MR1 is to resolve this issue:

    • Radius server should respond with a list of Groups via any defined attribute e.g. Filter-ID.
    • SFOS Radius server should have the same attribute set for “Group name attribute”.
    • Group should pre-exists in firewall to map user correctly in those groups.
    • In case group is not available in firewall user will fall in default group configured.

    Please take a look at authentication server log if correct group value is returning from Radius server against attribute configured in SFOS server for “Group name attribute

Reply
  • In v20MR1 we have fixed one Radius group membership issue listed below: 

    NC-127830

    Authentication

    RADIUS users who aren't part of VPN group are able to connect to SSL VPN.


    Prior to this fix
    : In scenario where user is part of  multiple groups and all groups are available in SFOS too. User group will be mapped to “Group and Other group memberships”.

    Now in case all the groups are removed from this user on Radius, in this case user’s “Group” value use to retain and hence user was able to access resources as per last group policy.

    Fix in v20MR1 is to resolve this issue:

    • Radius server should respond with a list of Groups via any defined attribute e.g. Filter-ID.
    • SFOS Radius server should have the same attribute set for “Group name attribute”.
    • Group should pre-exists in firewall to map user correctly in those groups.
    • In case group is not available in firewall user will fall in default group configured.

    Please take a look at authentication server log if correct group value is returning from Radius server against attribute configured in SFOS server for “Group name attribute

Children
No Data