RADIUS Authentication over Site-to-Site VPN

[Mark_Papworth]

I have set up a Radius Server to authenticate remote-access VPN clients. The Radius server is located at a remote site connected via Site-to-Site VPN on the same gateway the clients connect to.

Authentication fails because the request to the Radius server does not go through the VPN tunnel. Logs show traffic is accepted by an implied rule and consequently not encrypted.

[PhoneBoy · Accepted solution]

You need to disable the implied rule for RADIUS.
You can do that by editing the appropriate implied_rules.def, ensuring explicit rules exist for RADIUS where needed and installing policy.
Refer to: https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...

[Mark_Papworth]

Thanks. I couldn't figure out where to disable the implied rule.
We've established communication with the Radius server now.

[renanmvc]

What's the solution?

[Thomas_Eichelbu]

Hello, 

i have a question to this ...
when you have the firewall doing RADIUS over VPN, what is your source IP? is it the Firewalls external IP?
is it possible to set a specific outgoing IP address? So the closest IP pointing to the destination in easy words.
In a scenario of many many firewalls and NPS servers i want to limit the amount of IP address i have to set on NPS as NAS IP.

is there a way?

best regards

[PhoneBoy]

It should always use the "nearest" IP to the destination (according to the routing table). 

[Norbert_Giczi]

This worked perfectly with an MDS running on version R80.40 and (a specific CMA's implied_rule.def had to be modified) respective SG running on R80.40. However, it seems since we upgraded the MDS to R81.20 while the relevant SG is still running on version R80.40 this solution does not work any more. While RADIUS implied rule is disabled in the appropriate CMA's implied_rule.def (and policy install was also performed, of course), the behavior remains the original, so RADIUS traffic is still matched by the implied rule.

Any thoughts on this, please? Are you aware of any change in R81.20 or it is simply caused by the version difference between the management and the SG?

[PhoneBoy]

Changes made to .def files are not maintained across version upgrades.
Further, if you are managing older/different gateway versions, you will need to make a change in the relevant backward compatibility directory.
See: https://support.checkpoint.com/results/sk/sk92281

[Norbert_Giczi]

Thank you so much for your answer.

Now we can see where the problem lies: the implied_rules.def change was made in the wrong directory (to be more precise, not in the backward compatibility directory). In the meantime, it was decided to go with the SG upgrade to R81.20 and now the RADIUS traffic tunneling works as expected.