Advisory: Support Portal Maintenance. Login is currently unavailable, more info available here.
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:
Maybe things have changed?
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.
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.
"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.
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.
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.
One interesting note, if I load the same config into the official openvpn client I do get a push to the Duo app. It still fails, but when using the Sophos vpn client I don't get the push. The method of appending the code to the password also fails using the openvpn app. Something really screwy here, and the excuse of "we can't make it work for all 2fa providers" is a horrible cop-out. Everyone else has this working, and even if you can't fix it for every provider at least focus on the major players out there. Odds are 75+% of your customers that have 2fa in their environment are using one of the top 5 providers out there. There are pretty widely accepted standards for how most of this stuff should work, and a security company that can't support 2FA across the board on ALL of their products is not one that I want to continue investing in.
I saw this issue couple of weeks ago.
XG performs some kind of certificate (config) pinning in case of radius authentication.
Would highly recommend to talk about this with the Sophos Support because i saw the same anomaly by another customer with 2FA (Password). Radius tells us, everything is fine, XG tells us everything is fine but still AUTH_Failed in VPN (Client) but i did not follow up this issue in detail to give an advice for the reason.
FloSupport Maybe you can follow up this issue?
And again, i would love to have a configuable radius timeout - i really do. But i cannot change the fact how the product work. I know, Sophos is working on this and we can except something in the future. So stay tuned.
To add to what LuCar mentioned about support, please feel free to raise a support case and PM me with your case ID so that I can follow up with accordingly.
Talking to support about the issue is a whole lot of effort on your side to get support to tell you to submit/vote on a feature request - so the return on your investment of time isn't equitable. I've been able to determine that the support staff we speak to have no direct influence/contact with the development team. I can only surmise that the dev team looks at support data at the aggregate level when having meetings with product management on what to put into each release - and a lot of things at the aggregate that could be fixed or swiftly modified are lost. Effectively, we have no voice in the development of the XG product line. The UTM product line was in my opinion much better at this, but if you look at the history of the firewalls Sophos has produced, we see acquisitions at the heart of them and each acquisition comes with a different dev style. We've been promised feature parity with UTM9 would come since the first release of the XG/SFOS. The only reason I install XG/SFOS is to get Synchronized Security with endpoint and am evaluating whether or not it's worth it at this point.
I see two paths ahead:
- Put in all the effort to make a Sophos XG user group and occupy the Sophos HQ in each region with demands, because they certainly aren't doing it
- Change vendors
FloSupport I PM'ed you my new case #
I wanted to add an update. I haven't received any useful information from support yet. At first they told me this isn't supported, then said that it is, they'd test it in their lab environment, but I haven't heard anything back. Doing some more testing of my own I've found something interesting. Duo 2FA works perfectly on the user portal. The user portal seems to have a longer timeout, so using the Duo radius proxy I can login, receive a push notification on my phone, and get in after approving it in Duo. I'm not sure exactly how long the timeout is but it seems to be at least 30 seconds or more. It still does not work for the admin logins or vpn. I've also tested bypassing 2FA for my account in Duo, so it should just accept a straight username/password, but that also fails. So it appears that the admin and vpn logins process radius authentication completely different from the user portal and the "Test Connection" button when creating the radius server, because that shows successful authentication.
Can't they just make the other radius authentications work the same way as the user portal?? The XG is receiving a "success" message from the radius server, so I just don't understand why the XG recognizes that as a failed authentication when logging in one place, but recognizes it as successful in another. That just seems like poor design. Does that indicate lower security on the user portal, or just bad code on the others?