topic Re: Radius auth failover issue in Firewall and Security Management

Radius auth failover issue

the_rock — Fri, 22 Dec 2023 02:31:22 GMT

Hey guys,

Happy holidays! I wanted to see if someone could provide some thoughts/suggestions on this. So our customer has 2 radius servers, onprem and Azure. All this works fine, BUT, for 2 years now and multiple TAC cases, we still cant solve failover problem.

Btw, management is S1C and gateways are 6400s, R81.20 jumbo 41 (the latest)

What I mean by that is that say if onprem is priority 1 and Azure is priority 2 and you shut down onprem server, one would think that Azure would take over, but no, auth requests still seem to go to onprem server, as we can clearly see by doing tcpdump on port 1812. By the way, same issue happens if Azure is main auth server. One way to quickly solve issue when it happens is simply change the priorities of the radius servers and then all works fine after installing policy.

Also tested with both servers as priority 1, no luck.

We even set global auth to radius, made sure generic object in legacy dashboard was set to radius and tried any, radius group that contains both servers, no luck in any of scenarios.

TAC confirmed more than once that config is right, so it truly begs a question...WHY does failover scenario not work? Im not sure if anyone out there is using 2 radius server, but if you are, PLEASE let us know how you made this work (if you did lol)

Thanks again for all the suggestions!

Best,

Andy

Re: Radius auth failover issue

mccabe — Fri, 22 Dec 2023 12:27:35 GMT

Hi Andy,

I'm not sure from your post, but have you tweaked the settings for "radius_retrant_num" and "radius_retrant_timeout" as yet?

There's a long-standing SK here:

https://support.checkpoint.com/results/sk/sk42449

Re: Radius auth failover issue

the_rock — Fri, 22 Dec 2023 13:15:14 GMT

@mccabe Thanks for the reply. As a matter of fact, that was one of very first thing we did and did not change anything, TAC was even on the phone when it was done.

Best,

Andy

Re: Radius auth failover issue

the_rock — Fri, 22 Dec 2023 19:08:20 GMT

Just for the reference, we even tried both values to 1, but below are values TAC asked us to configure, exact same issue, no change.

Best,

Andy

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 13:54:47 GMT

@PhoneBoy Happy holidays mate! I wanted to pick your brain on this and see if you had any suggestions. Honestly, its nothing urgent, as issue has been there for more than 2 years now, so customer does not expect it to be fixed magically lol

Just wanted to see if you have anything on your mind that may help, thats all.

Happy New Year.

Best,

Andy

Re: Radius auth failover issue

Chris_Atkinson — Wed, 27 Dec 2023 14:33:35 GMT

Have you tried recreating the Radius server group in SmartConsole, does the current group name include special characters?

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 14:37:42 GMT

Yes we did, while back actually and name is Radius_group, but there was time it was called simply Radius and made no difference either.

Best,

Andy

Re: Radius auth failover issue

Chris_Atkinson — Wed, 27 Dec 2023 14:42:51 GMT

And to confirm when you say the Radius is shutdown they are not providing any response at all correct?

(Generally auth fail and timeout are not the same from a liveliness perspective)

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 14:43:45 GMT

Thats right, as if you shut down windows PC, not just rebooted it. Check out below, 192.168.x.x was the one that was shut down and 10.x.x.x is Azure one that was up and running.

Best,

Andy

[Expert@FW-1:0]# tcpdump -enni any host 192.168.32.210 and port 1812

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

20:46:20.795393 Out 00:1c:7f:a1:42:47 ethertype IPv4 (0x0800), length 116: 10.240.0.3.55059 > 192.168.32.210.1812: RADIUS, Access-Request (1), id: 0x29 length: 72

20:46:20.795396 Out 00:1c:7f:a1:42:47 ethertype 802.1Q (0x8100), length 120: vlan 20, p 0, ethertype IPv4, 10.240.0.3.55059 > 192.168.32.210.1812: RADIUS, Access-Request (1), id: 0x29 length: 72

20:46:25.795160 Out 00:1c:7f:a1:42:47 ethertype IPv4 (0x0800), length 116: 10.240.0.3.55059 > 192.168.32.210.1812: RADIUS, Access-Request (1), id: 0x29 length: 72

20:46:25.795163 Out 00:1c:7f:a1:42:47 ethertype 802.1Q (0x8100), length 120: vlan 20, p 0, ethertype IPv4, 10.240.0.3.55059 > 192.168.32.210.1812: RADIUS, Access-Request (1), id: 0x29 length: 72

4 packets captured

16 packets received by filter

0 packets dropped by kernel

[Expert@FW-1:0]#

Azure radius was not responding, so I changed priority to 1 for both and tested

[Expert@FW-1:0]# tcpdump -enni any host 10.200.11.14 and port 1812

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

0 packets captured

66 packets received by filter

2 packets dropped by kernel

[Expert@FW-1:0]#

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 14:54:19 GMT

Just verified now, group is called RadiusGroup, so no special characters anywhere.

Best,

Andy

Re: Radius auth failover issue

PhoneBoy — Wed, 27 Dec 2023 19:02:15 GMT

I believe it merely tries the RADIUS severs in priority order versus "failing over" to make one active or not.
At least that's how I remember this feature working back in the day.

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 19:04:57 GMT

Really? Hm, interesting...so I guess it sort of defeats the purpose then of having 2 radius servers for authentication. Any way to make it work with 2 of them in a group if say one is priority 1 and other is 2? We even tested the other night both as same priority and exact same issue.

Best,

Andy

Re: Radius auth failover issue

SenpaiNoticed_U — Wed, 27 Dec 2023 20:09:28 GMT

Try with Radius_connect_timeout at 20 seconds
keep the rest of the settings the same.

Let me know what the results are.

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 20:13:03 GMT

We did that long time ago and absolutely made no difference. We tried, 5,10,15,20,30 and so on, exact same issue.

Best,

Andy

Re: Radius auth failover issue

SenpaiNoticed_U — Wed, 27 Dec 2023 20:18:42 GMT

What about in the Iked files?
do we see it stopping and claiming all servers are down in the IKED due to timeout?

What I read that configuration as is
Attempt each server 2 times,
for 5 seconds between attempts
10 seconds for the whole authentication attempt before claiming all servers are down.

Thus never getting enough time to attempt a 2nd server due to the 1st server taking up (5+5) = 10 seconds

Re: Radius auth failover issue

the_rock — Wed, 27 Dec 2023 20:29:00 GMT

Absolutely nothing...TAC asked us for literally every log file you can imagine before and there was no solution. I think what @PhoneBoy said would explain why this does not work, but in all honesty, I find it shocking, because in my mind, it totally defeats the purpose of even having 2 radius servers at all.

Best,

Andy

Re: Radius auth failover issue

SenpaiNoticed_U — Wed, 27 Dec 2023 21:38:58 GMT

Seems to work with my Test Lab,
Radius servers in a group
Radius priority 1 = 10.250.250.1
Radius priority 2 = 10.150.150.2

Here are my settings in Global Properties

Re: Radius auth failover issue

SenpaiNoticed_U — Wed, 27 Dec 2023 21:50:21 GMT

Here is the auth page example

Re: Radius auth failover issue

the_rock — Thu, 28 Dec 2023 00:48:03 GMT

I hear ya, lots of things work in my lab too that dont work in production lol

Andy

Re: Radius auth failover issue

SenpaiNoticed_U — Wed, 27 Dec 2023 22:03:43 GMT

Then I suggest to work on your open TAC case, and showcase the issue, the traffic, and provide debugs/captures.