Skip to main content
J_J
J_J
Explorer
November 23, 2024
Question

RADIUS troubleshooting

  • November 23, 2024
  • 2 replies
  • 2206 views

I have 1 RADIUS group that has 3 Microsoft NPS server IPs (primary/secondary/tertiary).

 

through the GUI I have successful authentication to the Primary and am able to use my test user in the associated AD group.

 

the secondary fails, and I'm unsure of the tertiary due to my issue with this command to help me narrow things down server by server:

 

 

#diagnose test authserver radius-direct <server IP> <port> <PSK> <auth protocol> <username> <password>

 

when using this command in parallel with debug flow - it is using a source IP of the default mgmt 192.168.1.99 IP (the interface is disabled) - I then set the IP on the disabled interface to 0.0.0.0/0. 

 

the new debug shows the system using a 169.x.x.x address.

this is resulting in failed attempts as these are not the trusted IPs the NPS server is expecting...

 

when debugging to watch the flow of testing the credentials against the primary server via the GUI test button or using: 

#diagnose test authserver radius <servername> <auth protocol> <username> <password> shows it is using the configured #set source-ip in the RADIUS config. 

 

is there any fix for this command for me to source the IP that the system is utilizing it for to reliably test authentication against the specific servers within the group?

 

 

 

 

2 replies

dingjerry_FTNT
Staff
dingjerry_FTNT
Staff
November 23, 2024

Hi @J_J ,

 

Could you please share your Radius server configurations?  

    J_J
    J_JAuthor
    Explorer
    November 25, 2024

    Here are 2 examples on 2 different Firewalls:

     

    v7.2.9 build1688
    FG200F


    config user radius
    edit "FR-RADIUS"
    set server "172.16.189.16"
    set secret ENC <removed output>
    set source-ip "172.16.188.101"
    set secondary-server "172.16.177.35"
    set secondary-secret ENC <removed output>
    next
    end


    Secondary is connected and authenticating successfully, primary is failing.
    =======================================================================================

    v7.2.9 build1688
    FG200F

     

    config user radius
    edit "US-RADIUS"
    set server "172.16.161.5"
    set secret ENC <removed output>
    set source-ip "172.16.132.1"
    set secondary-server "172.16.153.11"
    set secondary-secret ENC <removed output>
    set tertiary-server "172.16.141.21"
    set tertiary-secret ENC <removed output>
    next
    end

     

    here the Primary is connected and authenticating successfully, the secondary on the GUI shows failed to connect, and I don't know about the Tertiary do to the issue with the command issues I'm having on the OP.
    =====================================================================================================================

    pminarik
    Staff
    pminarik
    Staff
    November 25, 2024

    What you're describing is a typical behaviour of local-out traffic traversing across an IPsec tunnel.

    By default traffic originated by the FortiGate will use the IP of the egress interface as source-IP. If that is not set (as can be true for IPsec tunnels), it will "fall back" to using the IP of some other interface.

     

    The solution is to either set an IP for your IPsec tunnel (this will be used by all local-out traffic), or to set the expected source-IP just in the RADIUS configuration, as you've done already in one of your snippets:

     

    config user radius 

    edit <name> 

    set source-ip <desired srcip>

    end

     

    There's some docs about this as well, e.g.: https://community.fortinet.com/t5/FortiGate/Technical-Tip-Source-IP-for-self-originating-IPsec-tunnel/ta-p/198591

     

    J_J
    J_JAuthor
    Explorer
    November 25, 2024

    Right, this makes sense.

     

    But I DO have source IP set and what I described on the initial post when running the first command i can see on debugs the Fortigate is not sourcing from the specified source in the radius config when running that specific command so i cant test the individual NPS servers individually, accurately. 

     

    As stated, the fortigate is using its default MGMT IP at first when the interface is not the egress interface to reach the server AND it is disabled - then when i quad 0.0.0.0/0 the interface just to see what happened it then used a source of 169.

     

    I have underlying connectivity to the servers that are failing to connect and authenticate, they ping and I've re-keyed them.

    pminarik
    Staff
    pminarik
    Staff
    November 25, 2024

    My memory is not perfect in this area, but I suspect that the default mgmt interface may be "dedicated to management", which means it's placed in a "hidden VDOM" and realistically useful mainly just for local-in traffic. (administrators connecting to the FortiGate)

     

    Check the routing table if the mgmt interface/ip is mentioned anywhere in there.

     

    https://community.fortinet.com/t5/FortiGate/Technical-Tip-HA-Reserved-Management-Interface-s-hidden-VDOM/ta-p/214783

    Terms & ConditionsAccessibility statement