Skip to main content
chethan
Explorer II
July 6, 2021
Question

FortiGate RADIUS Server Connectivity issue

  • July 6, 2021
  • 1 reply
  • 26358 views

Hello Everyone,

 

 From past couple of days we are facing this issue with FortiAuthenticator (RADIUS Server) Connection Status issue.

The connection status keeps on loading.

 

[ul]
  • The server secret is correct.
  • Can ping FortiAuthenticator from FortiGate.
  • Single factor authentication is working for remote RADIUS users.
  • FortiToken 2FA for remote RADIUS users is not working.
  • It was working before 4 days, no configuration was changed in between.[/ul]

    *Image Attached for reference* 

     

    Issue Resolving Urgency is high.

     

    Thank you.

     

     

  • 1 reply

    xsilver_FTNT
    Staff
    Staff
    July 7, 2021

    Hi,

    "Issue Resolving Urgency is high." :)  So you have a support contract and did open TAC ticket, and got that resolved already, right?

    Otherwise you haven't figured out that Forum is basically users-to-users support and we are helping here on voluntary basis.

     

    What would definitely help you and us to assess situation is:

    ---

    - software versions on both ends, FortiGate and FortiAuthenticator

    - FortiOS debug output 'diag debug application fnbamd 7' .. as that's the daemon responsible for almost all outer auth then debug might suggest

    - another hint might come from packet capture, like .. diag sniff pack any 'host <your-secret-FAC-IP> and port not 8000' 4 0 a

    To see at least if there is any request and response, or better with verbosity 6 instead of 4, or use GUI Packet capture, ideally on both ends to confirm traffic is flowing unchanged so there is no middle man/firewall there.

    Ideally there is supposed to be test RADIUS Access-Request from FGT to FAC with User-Name=test01 , followed by RADIUS response, probably Access-Reject .. to simply check there IS RADIUS service running on FAC

    - if single factor (password based probably) auth via FAC is working and 2FA is not, then it might be separate issue and I would suggest to have a look to respective RADIUS Service Policy on FAC.

    -- Is your requests matching right/intended policy (as order of the policies does matter)?

    -- Isn't there set "Password-only authentication" in side of 'Authentication factors'?

    -- Does the test user even have any 2FA set?

    - how is the authentication "for remote RADIUS users." set on FGT, all the requests goes to FAC, or are there locally defined users on FGT with 'set type radius' and pointing to FAC, if so then is the used username matching the record on FGT, because by default is FGT case-sensitive (as any Unix system). And that could be overriden in user config via 'set username-case-sensitivity'. As that's one of common caveats where non matching username + remote server in the same user-group on FGT (or worst: radius server on FGT with 'set all-usergruop enable') makes unintended fallback to remote server and avoid 2FA this way. But that's configuration mistake.

     

    - on FAC check that FGT is properly set as RADIUS Service Client and used in some Policy, as FAC will NOT respond to anyone without being set as known Client first!

    - and lately, check on FAC side .. GUI logs, and in GUI debug https://<FAC-IP>/debug/radius/  even basic output there might provide some hints and you can even turn RADIUS server to debug mode for increased verbosity of the log (I would not keep it in debug mode for normal operations so turn it off after troubleshooting).

     

     

    chethan
    chethanAuthor
    Explorer II
    July 8, 2021

    Thank you for replying,

     

    "I thought to find an answer on the forum before raising the support ticket".

     

    - The users are remote LDAP users (users are not local to FortiGate).

    - 2FA is set using FortiToken Mobile on FortiAuthenticator for users and it is how they are authenticated from its initial deployment.

    - Single factor works.

    - We are observing this from past 4 - 5 days, even though no configuration was changed in between (2FA was working fine before this).

    - On FortiAuthenticator Logs, I can see it is authenticating the Token as well successfully.

     

    I have run the required diagnostic commands on FortiGate:

    After entering the token, I can see that the traffic goes from FortiGate to FortiAuthenticator but never returns. On FortiGate it waits for the response from FortiAuthenticator for long enough to fail from timeout.

     

    I have attached the image below, It says "can't contact RADIUS server" even thought single factor still works.

    [ul]
  • We have checked the server secret on both FortiAuthenticator and FortiGate it is same.
  • On FortiAuthenticator policy, It is set to "Mandatory two-factor authentication". 
  • There is only one radius client (FortiGate) and it is used in the policy (only one policy defined).
  • No local users are created on FortiGate. All the requests go to FAC.[/ul]

     

    Thank you.

     

  • xsilver_FTNT
    Staff
    Staff
    July 8, 2021

    Excuse me but that's pretty weird.

    IF you have FGT pointing to FAC, where there is a single RADIUS Service / Policy .. allowing FGT as the only client, pointing users to realm which is LDAP based (probably to AD), AND the policy has "Mandatory two-factor authentication".

    Then how could it be that "Single factor works" as you state ?!

     

    If mandatory 2FA is set, and by any chance you will use user who has no 2FA set and fully activated on FAC, then such logon attempt will not ask for second factor, but it will also fail. Exactly because there was not possible to check second factor. Regardless of fact that same login user/pass will work if "Verify all configured authentication factors" would be set, so user without token will pass and user with token will be forced to use it (and fail without it).

     

    So, I would suggest to either open technical ticket, or follow your config ... how is RADIUS defined on FGT, how it's used in policy on FGT, check FNBAMD debug to see that right server is contacted (FAC), thne continue on FAC, in policy, all the sections, how backend is defined, what is default realm. If there is trully just one policy for that FGT as RADIUS Client, and what's on /debug/radius. Simply use packet capture or CLI 'exec tcpdump..' to confirm that FAC seen Access-Request, and sent back Challenge-Request for token .. and on FGT that such challenge was received and responded with new Access-Request where now User-Password APV contain token code.

    Alternatively you can trigger such user authentication from simple SSLVPN or even directly from CLI on FGT via 'diag test authserver radius <RADIUS-SERVER-NAME-from-ConfigUserRadius> pap <test-user-name> <password>'.

    If that test user is equipped with token then you should get token request even on FGTs' CLI.

     

    For example: (user A with token, user B without token, but policy enforce 2FA use)

     

    c-esx02 # diag test authserver radius C4 pap userb tester authenticate 'userb' against 'pap' failed, assigned_rad_session_id=264016458 session_timeout=0 secs idle_timeout=0 secs!

     

    c-esx02 # diag test authserver radius C4 pap usera tester Token Code:****** authenticate 'usera' against 'pap' succeeded, server=primary assigned_rad_session_id=264016465 session_timeout=0 secs idle_timeout=0 secs!

     

    c-esx02 #