Catch-all RADIUS client?

[ergotherego]

Running FAC 5.4.1 in HA.

We have several different RADIUS clients defined on our FAC. Mostly for VPN systems. Different systems use different realms, or are not sourced from contiguous IP space.

I would like to have our FortiGate administrator access controlled by FAC. However they all come from various IP space, and defining a RADIUS client for each one is not feasible.

I tried to define a new RADIUS client using client source IP of 0.0.0.0 and defined a matching RADIUS client attribute. However, what I observed is that the FAC matched this entry first, instead of matching the more specific RADIUS client entries with specific source IPs defined. Even after removing that entry, the matching still occurred as shown in the RADIUS debug logs. I had to reboot the FAC to get VPN authentication working again.

Is there a way to define a catch-all RADIUS client entry that is only used if a more specific entry does not match? Or a way to sort RADIUS client profiles to force which ones the FAC evaluates first?

[xsilver_FTNT]

Hi,

I'm probably missing how many FortiGates (FGT), where you want admin auth from FortiAuthenticator (FAC), you have.

If this si more than one FGT, then I guess those are coming to FAC through some management VLAN/NET, right? Alt. try to supernet those into some common subnet/range.

Q: Is there a way to define a catch-all RADIUS client entry that is only used if a more specific entry does not match?A:

AFAIK no, Clients are supposed to address specific NAS-es. And I would also suggest to consider this limitation as first step of protection. As attacker who is unable to fake correct NAS-ID or source IP will not be served.

If you do implement something like catch-all NAS, then you will disable/disarm this initial test/requirement and protection completely. For me it's bad idea.

Q: Or a way to sort RADIUS client profiles to force which ones the FAC evaluates first?

A:

Note in profile config states this clearly I think:

Profiles will be applied in top-to-bottom order based on matching RADIUS attributes.

If the profile has no attributes to match, that profile will always be applied before any beneath it.

So try to combine profiles, profile ordering and "Apply this profile based on RADIUS attributes." with realms.

Hint: if there is no matching realm in profile, user will be tried to authenticate against realm marked as 'Default'.

[ergotherego]

We have upwards of 500 FortiGates. Most are not using a common management subnet.

Profiles will be applied in top-to-bottom order based on matching RADIUS attributes.

There is no way I can see to control the evaluation of RADIUS client definitions when there is multiple matching source IP addresses. Ie, if one RADIUS client has source IP of 10.0.0.0/24 defined as the source, and another has 10.10.10.10/32 defined, the behavior of which will be examined first is not predictable. In my limited testing, the RADIUS session will be matched against the least specific (10.0.0.0/24) first - which is often undesirable. To combine profiles would require all all clients (profiles) use the same RADIUS PSK, which may not be desirable either.

Ideally the RADIUS client list would function more like a standard ACL ruleset. Where these rules can be sorted to force specific evaluation priority. Doing so would greatly increase the flexibility and power of the FAC system in my opinion. Additionally, each RADIUS client definition would support multiple source IP address entries, to accommodate disparate network segmentation present in the real world. So that a new system of the same type can be easily merged into FAC authentication, w/o having to replicate another RADIUS client definition.

Thanks for the reply. I will ask my SE about this.

[ergotherego]

After working with my SE I was able to get this working, specifying a range of "0.0.0.0-224.0.0.0".

I have several more specific entries based on source IP address that have continued to function normally after adding that new client.

Attached is screenshot showing how I configured it to specifically handle administrative access to FortiGate firewalls.

Edit: can't get image to upload. its here on imgur for the time being:

[link]https://imgur.com/AfpgsHz[/link]