Security

Hi,

Setting up a remote VPN solution using a 7210 controller (working to Clearpass).

For security reasons, I have placed the controller behind a firewall. This is having traffic hit the public IP; Checkpoint NATs this to an internal address which the controller has.

The checkpoint firewall is set to allow UDP&TCP 500/4500 - so should be all the IKE ports.

I can see traffic coming through; but when the controller starts to negotiate the traffic through UDP 4500; it fails and does not progress to this stage. It negotiates UDP500; the next part of this VPN should then be UDP 4500 but the controller never sees that phase.

I checked the firewalls logs; can see UDP4500 being sent but the controller doesn’t get that far when I check the controllers logs.

Does anyone know if there’s something different you need to do when the controller is behind a firewall with NAT? Is this checkpoint being funny? (I enabled any port on the rule to see and it still has same behaviour).

Do I have to do something to controllers internal firewall by default?

Thanks
#7210

Is this a site to site vpn?  If that is the case, you need to enable the "Enforce NAT-T" option in the site to site vpn configuration to only use UDP-4500

It’s a VPN solution for end users ... I can see from the logs that they start the negotiations on UDP 500, then it progresses to UDP 4500 and doesn’t go any further. Almost like it hits that port but can’t negotiate properly.

I’m struggling to see if it’s a config issue on the controller or something the firewall is doing with that port.

What client VPN is this?

 

If I had to guess, you are missing ESP or protocol 50  https://isc.sans.edu/diary/Cyber+Security+Awareness+Month+-+Day+30+-+The+%22Common%22+IPSEC+VPN+Protocols+-+IKE++ISAKMP+%28500udp%29%2C+ESP+%28IP+Protocol+50%29%2C+NAT-T-IKE+%28500udp%2C+4500udp%29%2C+PPTP+%28tcp1723%29%2C+GRE+%28IP+Protocol+47%29/7492

Will be using native Windows 10 client for VPN

If I test UDP4500 to the controller it shows it on the “show datapath session | include 4500” command

It shows when I generate some bogus traffic on that port ... I think this shows checkpoint is letting the traffic through.

This must be something on the controller not allowing the negotiations to proceed to the next phase?

Why don't you try a client on the same side of the firewall, so you can see all of the traffic...

I have seen in the past (that is 10+ years ago) issues with Check Point where it decapsulated UDP4500 traffic (into IKE/ESP) while it traverses the firewall. The firewall should not inspect/touch the traffic. I had to create a new service on udp port 4500 that does not do any inspection, and use that explicitly in the matching rule to prevent the firewall to touch the VPN traffic.

 

Did not touch a Check Point since long time, so can't really tell if this behavior is still the case or where to exactly click. Bottom line, the firewall may destination-NAT the traffic but should not touch it in other ways.

Good suggestion; the problem was the controller was NAT’d behind the gateway IP of the firewall itself. Proxy arp on a new public IP solved the issue.

Essentially, an implicit rule within Checkpoint was blocking this traffic as it must presume the traffic was destined for the gateway itself. Strange because it showed as accepted in the logs; but turn on accounting in the log and it shows zero packet size.

I enabled the NAT to work behind a different address in the public Ip subnet and it went through fine.

Got to love Checkpoint on stuff like this ...