RADIUS troubleshooting

[J_J]

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?

[dingjerry_FTNT]

Hi @J_J ,

Could you please share your Radius server configurations?  

[J_J]

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]

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-tunne...

[J_J]

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]

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-...