- Products
- Learn
- Local User Groups
- Partners
- More
Check Point Jump-Start Online Training
Now Available on CheckMates for Beginners!
Why do Hackers Love IoT Devices so Much?
Join our TechTalk on Aug 17, at 5PM CET | 11AM EST
Welcome to Maestro Masters!
Talk to Masters, Engage with Masters, Be a Maestro Master!
ZTNA Buyer’s Guide
Zero Trust essentials for your most valuable assets
The SMB Cyber Master
Boost your knowledge on Quantum Spark SMB gateways!
As YOU DESERVE THE BEST SECURITY
Upgrade to our latest GA Jumbo
CheckFlix!
All Videos In One Space
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)
By default, all outgoing traffic in ClusterXL mode is hiding behind VIP.
NTP, syslog, LDAP, RADIUS should go via VIP, not via members IP.
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?
By default, all outgoing traffic in ClusterXL mode is hiding behind VIP.
NTP, syslog, LDAP, RADIUS should go via VIP, not via members IP.
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?
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.
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.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY