Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Participant

RADIUS GAIA secondary unit not able to login

Jump to solution

Hi,

I'm using R80.20 and have configured RADIUS for GAIA on my primary and secondary unit. However when trying to login to the secondary unit, RADIUS fails to log me in. When I do a failover to the secondary unit RADIUS is functioning as expected but the other CheckPoint fails to log me.

So the primary unit can only authenticate through RADIUS. Any idea's on how to fix this or can someone explain why this is happening? (by the way, in all cases RADIUS shows an accepted authentication)

0 Kudos
1 Solution

Accepted Solutions
Highlighted

By default, all outgoing traffic in ClusterXL mode is hiding behind VIP.

NTP, syslog, LDAP, RADIUS should go via VIP, not via members IP.

Outgoing connections from cluster members are sent with cluster Virtual IP address instead of member...

There are a couple of ways how to exclude the RADIUS port to be hidden behind VIP. The best way is to create a NAT rule.

What is NAS IP configured on both nodes?

Kind regards,
Jozko Mrkvicka

View solution in original post

4 Replies
Highlighted

By default, all outgoing traffic in ClusterXL mode is hiding behind VIP.

NTP, syslog, LDAP, RADIUS should go via VIP, not via members IP.

Outgoing connections from cluster members are sent with cluster Virtual IP address instead of member...

There are a couple of ways how to exclude the RADIUS port to be hidden behind VIP. The best way is to create a NAT rule.

What is NAS IP configured on both nodes?

Kind regards,
Jozko Mrkvicka

View solution in original post

Highlighted
Participant
NAT rule solved the issue.
0 Kudos
Highlighted
Contributor

The solution and documentation provided by Jozko would be the ideal approach to this problem, but try running a zdebug + drop on the Active firewall while you attempt authentication to the Secondary.

Chances are the Radius access/accept packet might be dropped by the Active firewall since the return traffic would be sent to the Cluster VIP.

In some of the cases I worked with, setting the kernel parameter fwha_forw_packet_to_not_active to 1 fixed the issue. But this also depends on the drop logs seen on the Active firewall.

 

0 Kudos
Highlighted

Yes, the whole point of kernel parameter fwha_forw_packet_to_not_active set to 1 is to forward traffic from Active node towards Standby. I have also tested this solution, worked, BUT it is not recommended way and should be implemented as last resort.

Kind regards,
Jozko Mrkvicka
0 Kudos