Resources for the Check Point Community, by the Check Point Community.

Tim Hall has done it again! He has just released the 2nd edition of "Max Power".Rather than get into details here, I urge you to check out this announcement post. It's a massive upgrade, and well worth checking out. -E

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Managemnt Server sits behind NAT -SIC issues

I have a management Server with a private IP address and it sits behind a firewall and is NAT'ed to a static public IP.

It is then trying to establish SIC with a gateway(gateway has public IP) sitting on the internet.

I have read that the SIC certifcate uses IP address, which means the gateway on the internet is expecting the public IP address in the SIC cert, but instead there is a private IP. what is the work around for this issue ?

Re: Managemnt Server sits behind NAT -SIC issues

I have a management Server with a private IP address and it sits behind a firewall and is NAT'ed to a static public IP.

It is then trying to establish SIC with a gateway(gateway has public IP) sitting on the internet.

I have read that the SIC certifcate uses IP address, which means the gateway on the internet is expecting the public IP address in the SIC cert, but instead there is a private IP. what is the work around for this issue ?

any suggestions would be welcome.

Thanks
B

Happy New Year :-)

This is a well "known" issue since Checkpoint with AI R55.

On the Management server, there is a check box that you can enable to say that the management is behind a checkpoint firewall so that it will allow you to SIC with a gateway on the Internet. This is a work-around since R55.

Keep in mind that it will ONLY works with if the Management server is behind a "checkpoint" firewall trying to establish SIC with another checkpoint gateway over the Internet.

It will NOT work if the Management server is behind a "non" checkpoint gateways such as Cisco ASA, Juniper or PaloAlto. In that situation, you can NOT use NAT, it has to be routed.

Re: Managemnt Server sits behind NAT -SIC issues

Define a Secondary Management Server Object that has the Public IP as it's IP.

On the Gateway Object select the Secondary management server object as the Fetch Policy and where to Log.

Make sure that the Firewall between the Management Server and the Internet does the Static NAT, and is configured to allow the proper services through

Establish SIC with Gateway.

Works fine!

The Gateway before establishing SIC is open to the connection from ANY IP that provides the correct SIC Key. It then takes that IP as the "Management Server" which in this case would be the Public NATed IP.
When you push the policy down then it knows to send Logs to the Public IP and to Fetch Policy from the Public IP.

The ICA is the same that connecting too and so SIC works.

Is why when you move Managed Service Provider that you allow the new ISP's Public IP to connect and then it can push a policy and matches up with the SIC even though the IP address is now different of the Management Server.

Re: Managemnt Server sits behind NAT -SIC issues

Are you using automatic NAT? As long as you define the public IP in the NAT settings of the SMS object itself (rather than manually in NAT policy), and select "Apply for Security Gateway control connections", you should be all set. This handles both how the SMS presents itself to the remote gateway, and allows the communications to reach the gateway via Control Connections (implied rules).

Re: Managemnt Server sits behind NAT -SIC issues

My assumption was that something needed to be done in the masters file and a few changes via GUIdbEdit...but this is easier.

I will post an update with whatever works.

Thanks again.
B

This is what he is referring to. Remember, it only works with Checkpoint firewalls. If your management server is behind non-checkpoint device, it will NOT work with NAT and you will have to use routing method.

Re: Managemnt Server sits behind NAT -SIC issues

Remember, it only works with Checkpoint firewalls. If your management server is behind non-checkpoint device, it will NOT work with NAT and you will have to use routing method.[/ATTACH]

I don't see why not. As long as you've accounted for the same two concerns, you can do this through any device.

- Make sure the local firewall is NATing the SMS correctly and allowing the necessary services out

- Make sure the remote GW will accept the control connections from the NATed address

^ Second item is the tricky part, and the one most likely to cause problems. In my suggestion above, this is handled by the fact that the SMS object contains both private and public IP addresses in its definition. If we don't define the Static NAT on the SMS object, then the implied rules on the remote gateway won't recognize the address and the Stealth rule should drop the management traffic (it will also incorrectly try to deliver logs to the internal address).

This is where mcnallym's suggestion comes into play. The Secondary SMS object accounts for the Public IP and allows it to be manually selected as log/fetch object. Only issue here is the ever-present "fake" Secondary SMS - which you'll see in a problem state in Monitor.

As another [untested] idea, you could still define the Static NAT on the SMS object, even if you don't have a local CP GW performing the NAT. The remote GW should still know to use the NAT IP for control.

cciesec2006, while you're often (maybe even usually) spot on, I think you missed this one. It really points to what I love about technology, and why I've made a career out of it: There's always a way. Of course, that "way" can often be too costly or problematic to be worth it, but it's finding that way that I find thrilling and rewarding. I get excited whenever I hear "it can't be done" or "it will NOT work" ;)

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by EricAnderson

cciesec2006, while you're often (maybe even usually) spot on, I think you missed this one. It really points to what I love about technology, and why I've made a career out of it: There's always a way. Of course, that "way" can often be too costly or problematic to be worth it, but it's finding that way that I find thrilling and rewarding. I get excited whenever I hear "it can't be done" or "it will NOT work" ;)
-E

Ok, I might be too harsh on this :-). My philosophy is "Keep It Simple Stupid" KISS

I used to work for a Managed Service Provider (MSP) and we managed firewalls over the Internet for lot of customers and we NEVER implement it this way because of complication and everyone skills level is not the same.

You can make thing simple by:

1- routing on the firewalls instead of NAT'ing,
2- create VPN between two sites on non-checkpoint and have your management traffics between SMS and gateways

Re: Managemnt Server sits behind NAT -SIC issues

Define a Secondary Management Server Object that has the Public IP as it's IP.

On the Gateway Object select the Secondary management server object as the Fetch Policy and where to Log.

Make sure that the Firewall between the Management Server and the Internet does the Static NAT, and is configured to allow the proper services through

Establish SIC with Gateway.

Works fine!

The Gateway before establishing SIC is open to the connection from ANY IP that provides the correct SIC Key. It then takes that IP as the "Management Server" which in this case would be the Public NATed IP.
When you push the policy down then it knows to send Logs to the Public IP and to Fetch Policy from the Public IP.

The ICA is the same that connecting too and so SIC works.

Is why when you move Managed Service Provider that you allow the new ISP's Public IP to connect and then it can push a policy and matches up with the SIC even though the IP address is now different of the Management Server.

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by cciesec2006

Ok, I might be too harsh on this :-). My philosophy is "Keep It Simple Stupid" KISS

I used to work for a Managed Service Provider (MSP) and we managed firewalls over the Internet for lot of customers and we NEVER implement it this way because of complication and everyone skills level is not the same.

You can make thing simple by:

1- routing on the firewalls instead of NAT'ing,
2- create VPN between two sites on non-checkpoint and have your management traffics between SMS and gateways

both method #1 and #2 are widely used by a lot of people.

I agree that not the best way of doing it, it also means that cannot implement Management HA ( if you want ) as can only define two Management Server objects. We use a Public IP Range on our MDS and simply route that IP through the perimeter firewall. Also helps ensure that no issue in terms of the Physical IP of the Management conflicting with the Internal Networks used at the Customer if need to VPN the Management Server through to the Customer.

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by mcnallym

I agree that not the best way of doing it, it also means that cannot implement Management HA ( if you want ) as can only define two Management Server objects.

Not true! Have you tried this? Just because all additional Management Servers are labeled "Secondary" during install, that doesn't mean they can't be tertiary, quaternary, quinary, etc (I had to look those last two up). Should work, but the "fake" one will always be "unhappy". Is there something else keeping you from doing it?

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by EricAnderson

Not true! Have you tried this? Just because all additional Management Servers are labeled "Secondary" during install, that doesn't mean they can't be tertiary, quaternary, quinary, etc (I had to look those last two up). Should work, but the "fake" one will always be "unhappy". Is there something else keeping you from doing it?

-E

I am in complete agreement with mcnallym. Of course, all of us are here to solve problem and probably 99.99% of the times, the problem can be solved. That's what engineering is all about.

That being said, just because it can be done does not mean one should do it. It is like driving not legally drunk. Yes, I can have my blood alcohol level below .08 (legally in most states) and can still legally operate a vehicle and yes it is within my legal right to do so but it does not mean that I should do it.

One of the things that I've learned over the years is to keep things as simple as possible so that it will make thing easier for people for who have come after I leave a company. I hope the new company that I will be working for, the same courtesy will be applied to me from people who previously work there. These days, it is extremely rare for someone to work at the same company for more than 20+ years (those days are gone).

All of us in technology, myself included, not to the faults of our own, tend to be selfish and just want to solve the issue at hand, and not think about the consequence down the road for someone else.

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by EricAnderson

Not true! Have you tried this? Just because all additional Management Servers are labeled "Secondary" during install, that doesn't mean they can't be tertiary, quaternary, quinary, etc (I had to look those last two up). Should work, but the "fake" one will always be "unhappy". Is there something else keeping you from doing it?

-E

Yes, if login to a System that has the DMN-Server and already has a Secondary Management Server Object defined then when you attempt to create a new Check Point Object and select the Management Tab followed by Network Policy Management then throws up an error.

You cannot define more then one Security Management Backup servers

Could be because I only really work with MDS these days, working for an MSP so don't tend to have much to do with SmartCentre anymore. Possibly SmartCentre is different however certainly in an MDS environment if try and define additional Management Server Objects then throws out the error.

Re: Managemnt Server sits behind NAT -SIC issues

Originally Posted by mcnallym

Yes, if login to a System that has the DMN-Server and already has a Secondary Management Server Object defined then when you attempt to create a new Check Point Object and select the Management Tab followed by Network Policy Management then throws up an error.

You cannot define more then one Security Management Backup servers

Could be because I only really work with MDS these days, working for an MSP so don't tend to have much to do with SmartCentre anymore. Possibly SmartCentre is different however certainly in an MDS environment if try and define additional Management Server Objects then throws out the error.

hmm interesting. I'm looking at a CMA that has 2 secondaries using this method right now. One being the dummy object the other being a legit secondary.

Re: Managemnt Server sits behind NAT -SIC issues

I have tried on CMA's that clean created on R77.30 and also ones in R77.30 that migrated across from previous releases.

Has the DMN Object which is Primary

Lets me create a Host enable the Network Policy Management which also ticks the Secondary part

Go to create another new Host, enable the Network Policy Management and returns the error that provided.

Tested in Demo Mode on an R77.30 SmartConsole in SmartCentre mode and that does allow me to create a 3rd Management Server Object.

Was your CMA imported from a SmartCenter that already had multiple Management Servers created already?

R77.30

This MDS goes waaaay back. I think it started in FP era. I know p1 wasn't around around then just saying stuff has been upgraded export/imported etc. This CMA was copied from a different CMA at R71 if I recall. The 2 secondaries where created at that time.

Re: Managemnt Server sits behind NAT -SIC issues

Auto-nat is good when a Check Point is doing the NAT when it isn't a Check Point, as in management on AWS, you need to do the following:

Manager's object Main IP Address set to the Public IP
Manager's topology contains all interfaces' primary IP address
On the OS side add the public IP as an alias to the interface the traffic should traverse.
On Gaia the command is "add interface eth0 alias 1.2.3.4/32" in the webUI you cannot set a 32 bit netmask.