RADIUS authentication fails due to replacement servers

[Howard_Gyton]

We have two RADIUS servers that are used for VPN authentication, and authentication to the firewall manager. running 81.20.

I have built two new RADIUS servers, importing the config from the current servers.  Old servers are Server 2016, new ones are Server 2025.

I have disabled the NICs on the 2016 servers, and given the new servers the same IP's that they had, in effect swapping servers -03 & -04 with servers -07 & -08.

What we found was all other aspects of authentication are working fine, but it breaks the VPN, and I cannot authenticate to SmartConsole either.  Local admin accounts work fine.

Making the old servers live again fixes things.

The only thing  I can think of is the label of the server in the database.  I left the names as -03 & -04, so are there some additional checks that Check Point does that other systems do not?

For example, one of the objects:

We have a similar process for other Eduroam servers, and we haven't yet renamed their objects, and they are still working.  Our Aruba wireless system, for example.  My assumption was that as long as the shared secret was correct, the label of the object didn't matter, but perhaps in this case it does?

[Amir_Senn]

I suggest going to old Radius object in the objects bar -> right click -> where used.

Perhaps this can help discover if it's being referenced in other object.

[Howard_Gyton]

The only places those two objects are used are in a group called "AD-Radius", which is in turn used for VPN authentication:

Also for administrator user account authentication:

I would have thought these would be fine inheriting the IP addresses.  When I get the opportunity to try again, I may rename the the 03/04 objects to 07/08, and re-test.  If that fails I'll log a ticket with our support partner.