Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Tom_Heesmans
Contributor
Jump to solution

RADIUS GAIA secondary unit not able to login

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
JozkoMrkvicka
Authority
Authority

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
JozkoMrkvicka
Authority
Authority

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
Tom_Heesmans
Contributor
NAT rule solved the issue.
0 Kudos
Udupi_krishna
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
JozkoMrkvicka
Authority
Authority

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

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events