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

Always-On VPN through a Checkpoint FW

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?

Capture.PNG

0 Kudos
2 Solutions

Accepted Solutions
Bob_Zimmerman
Authority
Authority

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.

View solution in original post

0 Kudos
Bob_Zimmerman
Authority
Authority

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'.

View solution in original post

3 Replies
Bob_Zimmerman
Authority
Authority

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.

0 Kudos
Rccou
Participant

Is this any different with a ClusterXL deployment?

Are there any global settings which might be making this not work?

0 Kudos
Bob_Zimmerman
Authority
Authority

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.

Upcoming Events

    CheckMates Events