- Products
- Learn
- Local User Groups
- Partners
- More
MVP 2026: Submissions
Are Now Open!
What's New in R82.10?
Watch NowOverlap in Security Validation
Help us to understand your needs better
CheckMates Go:
Maestro Madness
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'.
Leaderboard
Epsum factorial non deposit quid pro quo hic escorol.
| User | Count |
|---|---|
| 14 | |
| 10 | |
| 9 | |
| 7 | |
| 6 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Fri 12 Dec 2025 @ 10:00 AM (CET)
Check Mates Live Netherlands: #41 AI & Multi Context ProtocolTue 16 Dec 2025 @ 05:00 PM (CET)
Under the Hood: CloudGuard Network Security for Oracle Cloud - Config and Autoscaling!Thu 18 Dec 2025 @ 10:00 AM (CET)
Cloud Architect Series - Building a Hybrid Mesh Security Strategy across cloudsAbout CheckMates
Learn Check Point
Advanced Learning
YOU DESERVE THE BEST SECURITY