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 with 2factor timout

In Sophos XG, is there any way to increase the timeout for radius servers?

I'm having problems using SSL VPN authentication with radius when using 2-factor. If I bypass 2factor, I'm logging in fine.

If I enable 2factor, it seems to timeout and I get a second credential prompt before I get to accept the first request, rendering my first request invalid.

I've seen this question before and the answer was that the timout is hard coded. However that was a old thread:

http://feature.astaro.com/forums/17359-utm-formerly-asg-feature-requests/suggestions/2812151-authentication-configurable-radius-timeout

Maybe things have changed?




[locked by: FloSupport at 7:57 PM (GMT -7) on 25 Mar 2019]
Parents
  • I recently opened a support ticket with Sophos to get an update about this. Below is the response I have received (spoiler: issue is not resolved yet).

    "About this [NC-8393] the bad news is that there is not a work around with Radius, however as a "work around" for dual authentication that another client have been using is with Google Authenticator or using the firewall. 

    This function is coming in an upcoming release of the 17 version, 17.3, but it might be before due to the demand about this feature with Radius."

     

    I asked for further clarification regarding what the support engineer meant when he said "using the firewall" is a work around, even after he directly said that there is no work around with RADIUS. I also asked for further clarification regarding when version 17.3 might be released. I'm awaiting further details on both of these follow ups.

Reply
  • I recently opened a support ticket with Sophos to get an update about this. Below is the response I have received (spoiler: issue is not resolved yet).

    "About this [NC-8393] the bad news is that there is not a work around with Radius, however as a "work around" for dual authentication that another client have been using is with Google Authenticator or using the firewall. 

    This function is coming in an upcoming release of the 17 version, 17.3, but it might be before due to the demand about this feature with Radius."

     

    I asked for further clarification regarding what the support engineer meant when he said "using the firewall" is a work around, even after he directly said that there is no work around with RADIUS. I also asked for further clarification regarding when version 17.3 might be released. I'm awaiting further details on both of these follow ups.

Children
  • I have a further update and a correction from support:

     

    The fix for NC-8393 will be available in version 17.2 which is due to be released between September or October of this year (2018). Version 17.1 is coming out in the summer but won't have this feature. 

    As for the workaround provided, Google Authenticator is apparently one way to go but saying that the firewall could also be used was a typo. Instead the support engineer meant that One-Time Password could be used in place of multi-factor authentication. OTP can be used for WebAdmin, User Portal, SSL and IPSEC remote access.

  • Will this fix be included in 17.5 or will it be a release before that point (we're on 17.1.3 now)?  This timeout is holding back our implementation of 3rd party 2fa/mfa--the OTP on the XGs is great, but when you have lots of them and lots of other 2fa/mfa in the environment, we really want to try and centralize a bit.

    Thanks!

  • Seems like it is postponed to V18. 

    V17.5 is in Beta and all features are included. No Radius timeout there.

    But - do not forgot, most of the time, the value of XG (30 sec) can be configured on the 2factor system. So it should be possible to use those systems.

    Had a discussion with a smaller vendor of 2factor. This vendor was a startup - so he was able to change quickly in his product and could adjust this value fast in his system. 

    __________________________________________________________________________________________________________________

  • Is Sophos's response really that all the 2FA companies should change rather than Sophos?

    A simple change for Sophos on a patch release would be to make the timeout 60 secs whilst we wait for it to be configurable?

  • It is not quite that simple to change this value. So there are reasons behind this change postponed to V18. 

    And i gave you a simple workaround or at least a way to ask your 2FA Company vendor. Maybe there is a way to change it, maybe there is not. 

     

    And if this change would be as simple as you suggest, why could not the 2FA vendor change this value? 

    __________________________________________________________________________________________________________________

  • Because it is not just one 2FA provider that has this issue and when you have many customers using many different 2FA providers; we don't have relationships with all of them.

    There is one common denominator in the XG which would be the logical place to fix this issue.

    In the meantime, customers wait or select/change to new NGFW providers.

  • "But - do not forgot, most of the time, the value of XG (30 sec) can be configured on the 2factor system. So it should be possible to use those systems."

     

    This statement is inaccurate. The timeout comes from the XG. It doesn't matter what you have set on the 2FA end, if the XG is expecting a yes/no response from radius within a certain amount of time, it doesn't matter what is set anywhere else, it is going to fail the login once that time has passed.

     

    If I am misunderstanding this statement or wrong, please post instructions on how you have gotten this to work in any 2FA system. Even though we all use different 2FA providers your instructions would probably be relevant for other products, since most work in fairly similar ways.

     

    Radius is typically the easiest way to get 2FA working. I even had it working on my ancient cisco ASA before switching to an XG. If I'd have known something so simple (that also provides a hell of a lot of security) wouldn't work I would have never gone with Sophos.

  • It still depends on the software, you are using to get 2FA. 

    For example, there are 2FA vendors who builds the same OTP like we do via radius (insert the password + OTP token in the same field), which works fine. Radius server gets the challenge and can respond within the timeout value.

    But other 2FA mechanism like SMS, Mobilephone app etc. are not quite fast enough to get done until the timeout hits. I had the wrong information - we are working with 3 seconds plus 1 retry. So basically you have 6 seconds to complete the challenge. 

    As mentioned earlier, i am not a developer or Product manager so basically i can only tell you my experiences. 

    __________________________________________________________________________________________________________________

  • Hi Lucar,

    It is valiant that you are trying to placate and resolve this conflict but it is plain and simple that it has been a feature request since v16, the UTM got it but the XG did not. It is bad taste as there has been very little interaction with the feature request for anyone to believe it is coming. Wait timeouts are not a complex thing to develop and account for and needing to do an architectural rewrite just to allow this either indicates a poorly designed RADIUS authentication system (i'll reserve my more choice comments on RADIUS on the XG as I have other outstanding issues with PMs opinions on other topics in this area) or Product Management do not deem this feature a necessity.

    Simply put, it has not been given development time (visibly) for the 2 years the request has been active and to wait another year for the v18 release is souring. Right now, every feature request (big or small) appears to be getting the "scheduled for v18" so if v18 doesn't clear the first 10 pages of the feature request portal for the XG, there will be riots.

    Just two cents on this discussion.

    Emile

  • Well put. I strongly agree. One issue I'm testing out right now is that the XG doesn't even seem to work with some 2FA systems no matter what method is used. For example, using Duo I should be able to append a code generated by Duo's app to the end of the password. This would resolve the timeout issue in theory, since the 2fa is passed along with the password (the format is password,123456). But using this method (which works fine on an ASA and several other radius devices I've tried it on) generates an AUTH_FAILED error in the client log. Also placing the Duo account in bypass mode, which means there is no 2fa even required, generates the same AUTH_FAILED error. The really interesting thing is that in the XG console when editing the Radius server if I use the "Test Connection" all methods work. I can use push, or pass the code through with the password, and it also works in bypass mode. So for some reason this works fine when testing the account authentication, but something breaks when it is selected as the authentication source for vpn. When I check logs on the XG and on DUO to look at these failed authentication attempts the XG and Duo both show successful authentications. So there's some issue with whatever is being sent between the XG and the vpn client, and not just a timeout problem.