Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 15339 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SSL VPN - Radius User Authentication doesn't work

mod2402
Hi all,
I've a Problem with the SSL VPN Client. When I add the Radius Users Group into the SSL VPN Profil, users can't login with this group. The Radius Server is a Celestix Hotpin OTP Server.  

There is no Problem with the User Portal. At this place the Radius Users group work fine. Just the SSL VPN with Radius users dosen't work. Is this a bug? When I use Active Directory Groups, all user could login.

In the SSL VPN Clientlog I see Auth Failures.

Here is the Log from the asg:
2013:11:02-20:24:29 asg-1 openvpn[1787]: 109.41.***.***:52553 TLS: Username/Password authentication deferred for username 'klaus' [CN SET]
2013:11:02-20:24:29 asg-1 openvpn[1787]: 109.41.***.***:52553 TLS Auth Error: --client-config-dir authentication failed for common name 'klaus' file='/etc/openvpn/conf.d/klaus'

Any Suggestion?

Thanks,
mod
UTM 9.106-17 / HA running on Hyper-V


This thread was automatically locked due to age.
  • 0
    Hi mod,

    do you have created just the user group (as backend group) on your utm? I think that doesn't work. You have to create the signle users as backend-authenticated users on your utm to use them for ssl vpn.

    Regards
    Manfred
  • 0 in reply to Hallowach2
    Hi Manfred,

    I've created a backend radius user group on the utm. The user account is an autogenerated remote account. not a local account. This user login works with the user Portal but doesn't work for ssl vpn.

    When this is a normal behavior, I think its time for a feature request. Thats a must have for a professionell Firewall. Many customers need radius authentication for vpn's.

    regards
    mod
  • 0
    ok, the 9.2 have many improvements and new OTP support Options. I will take a look to the new beta release.

    mod
  • 0
    Hm - I have no personal experience with autocreated user accounts - I know that Radius does work with manually created local user in 'backend authentication mode' as long as your radius server is configured as the only auth server (or at least at the top of the list). Did you check the authentication logfile for useful hints?

    Regards
    Manfred
  • 0 in reply to Hallowach2
    The radius server is configured on top of the list. this works when the user login to the user Portal but doesn't work for ssl vpn.

    The Auth log for internal user Portal Login that works:
    2013:11:03-20:19:55 asg-1 aua[3051]: id="3006" severity="info" sys="System" sub="auth" name="Child 22955 is running too long. Terminating child" 

    2013:11:03-20:19:55 asg-1 aua[23255]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.***.*** (radius)" 

    2013:11:03-20:19:56 asg-1 aua[23255]: id="3004" severity="info" sys="System" sub="auth" name="Authentication successful" srcip="192.168.***.***" user="klaus" caller="portal" engine="radius"

    The Auth log for ssl vpn Login that doesn't works:
    2013:11:03-20:23:14 asg-1 aua[3051]: id="3006" severity="info" sys="System" sub="auth" name="Child 23255 is running too long. Terminating child" 

    2013:11:03-20:23:14 asg-1 aua[23657]: id="3006" severity="info" sys="System" sub="auth" name="Trying 192.168.***.*** (radius)" 

    2013:11:03-20:23:14 asg-1 aua[23657]: id="3005" severity="warn" sys="System" sub="auth" name="Authentication failed" srcip="109.44.***.***" user="klaus" caller="openvpn" reason="DENIED" 

    2013:11:03-20:24:15 asg-1 aua[3051]: id="3006" severity="info" sys="System" sub="auth" name="Child 23657 is running too long. Terminating child" 


    I think there is a Problem with the otp token that times out. but why this works for the user Portal? is that just a problem with external access? I think it's a bug.

    €dit
    The Radius Server generates the following Event:
    Network Policy Server granted access to a user.

    User:
    Security ID: NULL SID
    Account Name: klaus

    regards
    mod
  • 0
    The SSL VPN requires a certificate for the user.  That requires that a user be created in the UTM.  The only reason for a RADIUS Backend Group there would be for the definition of the SSL VPN Profile.  I don't know that it works as I've not tried it.  I guess that the best test would be to set User auto-creation for User Portal Access - that would offer the best chance for success.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0
    Hi Bob,
    thanks for your reply. I've added the autogenerated user to the ssl vpn Profil. Same behavior.. Any other suggestion?

    Regards
    mod
  • 0
    Hi mod,

    did you fetch a new client config for the ssl vpn client after you added the user to the vpn profile via the user portal or the user/group config section? How do you have created the ovpn file without the user beeing member of a ssl vpn profile?

    An other question is the source ip adress in the failed connection attempt - who is "srcip="109.44.***.***" "?

    You can change the timeout for the radius authentication in /var/aua/AuaConfig.pm. You have to restart the aua deamon or reboot the utm to activate the change.

    Regards
    Manfred
  • 0
    Hi Manfred,
    this was my own fault. I've fetched the new Client config with the Admin account and not with the user account. Now it works like a charm. I don't need to add the autogenerated user to the ssl vpn Profile. I add the radius user Group to the Profile and this works fine for me.

    Now I can use both Authentication modes. AD Authentication for the User Portal and Radius User (OTP) Authentication for the ssl vpn. Both with the same username [:)]

    Thanks Manfred and Bob for your support.

    Regards, 
    mod
  • 0 in reply to mod2402

    Hey ho @all:

    we had the same problem with our UTM and Vasco Token Server.

     

    Specs:

    UTM ASG425 - 9.409-9

    NPS - MS Server 2012

    TOK - Vasco Token Server - MS Server 2012 R2

     

    Config:

    UTM has a configured AD as adirectory (and switched on auto creation of users) and our NPS as radius-server. In case a user want to go to his webportal, he can use the adirectory login. SSL VPN is set to the radius group, which uses the NPS radius server. Our NPS just redirects the NAS identifier "ssl" to our TOK.

     

    We used tcpdump on the UTM and recognized, that our TOK/NPS always replied a successful validation of the SSL VPN user credentials, but the UTM denied the login. We are using the Sophos VPN Client (OpenVPN 2.3.8 i686-w64-mingw32 [SSL (OpenSSL)] [LZO] [IPv6] built on Jun 25 2016) to connect to our UTM. After a few hour of searching and tcp dumping, we figured out:

    - The users in the "Users & Groups" management only get the "Definitions & Users → Users & Groups → Groups → Radius Users" flag, when they logged into the WebPortal of the UTM or via VPN.

    - The UTM login is CASE SeNsItIvE. We recognized this point by just allowing the users to login via radius and not AD groups to the web portal. we got duplicated users. F.e. User ABC via AD sync and user abc via radius login.

     

    our not so nice solution: if the user doesn't have the Radius Users flag, he has to login with capital letters (ABC). The UTM gets a success message from the NPS and because it's case sensitive, it can update the auto generated AD user ABC and add the Radius User flag. Afterwards it's independant, wether the credentials are captial letters or not ;-) So we tell our users, they should always use capital letters :-) Now the login for ssl vpn works for our users with OTP via radius (NPS/TOK) and for the UTMs user portal via AD.

     

    EDIT: There is already a bug report for this thing: https://community.sophos.com/products/unified-threat-management/astaroorg/f/utm-9-2-beta/65478/9-191-bug-otp-enabled---username-case-sensitive

    It's possible, that in case of a completly fesh installed UTM, this problem will noc occur any more, but we are updating our utm for a long time ;) 

     

    --- sorry for the confusing description, but it was a loooong day until we figured and changed the config. hope it's understandable in some way ;-)

Unfiltered HTML