- 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 Everyone.
I'm trying to help my users set up a Microsoft Always-On VPN server through a Checkpoint FW.
This is the first time I've tried to publish a server to the internet using CP and R80 so I don't know if i'm doing it wrong or if it's just not working.
I am using R80.30.
I have created my public IP object (from within my internet /26) and configured the NAT which automatically creates the NAT rules. Is this all there is to it to publish a server through the FW?
I have added a policy rule for IKE and IKE-NAT-Traversal from all the internet, as the source, towards the NATted internal IP address as the destination.
Should I see hits on this rule?
I have also configured additional rules for RADIUS traffic from the internal interfaces of the AOVPN RAS servers towards the Microsoft NPS servers.
None of this is working and I don't really know where to look first. We have confirmed using wireshark on the remote client that no reply traffic is being received..
Am I doing it all wrong?
You should probably configure the object the other way around. Give it the real internal IP, then in the NAT section, apply automatic static NAT for the public IP. This adds proxy ARP entries to the firewall to cause it to claim to own the IP if something on the wire ARPs for it. If the /26 block is routed to the firewall, this wouldn't matter, but the fact you don't see hits on the rule makes me suspect your public block includes the firewall, and you're missing the proxy ARP entry.
When an object has automatic NAT rules applied, it generally counts as both the real IP and the NATed IP in rules. There are a few weird exceptions, but you should be fine with a rule allowing any source (or negated RFC 1918, or whatever you want to do which represents the Internet) to talk to your object on IKE, IKE-NAT-Traversal, and so on.
No different for a cluster. The members each figure out the right MAC for the automatic proxy ARP.
There is a global setting somewhere (can't quite remember exactly where) to merge manual and automatic proxy ARP configuration. With that checked, both will work. Without that option checked, automatic will work and manual won't. You can check which proxy ARP entries your firewall has using the command 'fw ctl arp -n'.
You should probably configure the object the other way around. Give it the real internal IP, then in the NAT section, apply automatic static NAT for the public IP. This adds proxy ARP entries to the firewall to cause it to claim to own the IP if something on the wire ARPs for it. If the /26 block is routed to the firewall, this wouldn't matter, but the fact you don't see hits on the rule makes me suspect your public block includes the firewall, and you're missing the proxy ARP entry.
When an object has automatic NAT rules applied, it generally counts as both the real IP and the NATed IP in rules. There are a few weird exceptions, but you should be fine with a rule allowing any source (or negated RFC 1918, or whatever you want to do which represents the Internet) to talk to your object on IKE, IKE-NAT-Traversal, and so on.
Is this any different with a ClusterXL deployment?
Are there any global settings which might be making this not work?
No different for a cluster. The members each figure out the right MAC for the automatic proxy ARP.
There is a global setting somewhere (can't quite remember exactly where) to merge manual and automatic proxy ARP configuration. With that checked, both will work. Without that option checked, automatic will work and manual won't. You can check which proxy ARP entries your firewall has using the command 'fw ctl arp -n'.
About CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY