Connecting a remote gateway on the Internet to our SMS

[FtW64]

This is driving me nuts!

I'm trying to setup communication between a Security Management Server (SMS) and a remote Check Point gateway (RGW) connected only to the Internet. We also have a local gateway (LGW) that sits between the SMS and the Internet. The SMS has an internal private IP address.

I have 'Accept Control Connects: "First"' disabled in the global properties.

Attempt 1: Add a manual NAT (hide) rule on LGW to translate traffic from SMS to RGW to a public (source) IP address.

OKAY: Now I can perform a SIC with the RGW and I can install a policy to the RGW.

FAIL: However, I cannot get log traffic (port 257) from the RGW to the SMS (this traffic is destined from the RGW to the internal private IP address of the SMS; this traffic cannot pass the Internet).

Attempt 2: In addition to attempt 1 I ADD a manual NAT rule on the RGW to translate traffic from RGW to the internal IP address of SMS, to the public IP address of SMS. I also created the appropriate access rules to allow for control traffic on the RGW.

FAIL: The RGW simply ignores the NAT rule for traffic to the SMS on ports 257 and 18264.

Attempt 3: I removed all manual NAT rules and enabled automatic static NAT on the SMS object, including the option "Apply for Security Gateway control connections" and "Install on gateway: LGW". I also created the appropriate access rules to allow for control traffic from the RGW to the SMS.

OKAY: Log traffic from the RGW to the SMS now uses the public IP address of the SMS

FAIL: I still see traffic (attempts) from the RGW to the SMS to port 18264. Sometimes I also see attempts from the RGW to the SMS to access port 18191 as well... Both streams use the internal private IP address of the SMS.

What am I doing wrong and am I missing something here? It seems such a simple task, but I fail to get it right...

P.S. I'd rather not like to use a VPN between the two gateways (LGW and RGW) and pass the control traffic over that tunnel. First, this is not recommended by Check Point, and second: if the VPN fails I cannot control the RGW or get any logging out of it...

Regards,

-Frank

[the_rock]

Ok, dont despair, community always comes through for people...we will help you out! Just working on something atm, but let me read this carefully in a bit and see why it fails.

Best,

Andy

[the_rock]

Ok, since I am talking a break from some work stuff, let me try to "paint" the picture here, though simple diagram may help. So, there is SMS thats managinb LGW and also RGW and if I get this right, policy works fine for both, ONLY logs are not working from rgw to the sms, corretc? If so, can you follow below steps from the sk and see what you get. Because to me, logically, if policy works, that 100% confirms that connectivity is there.

Best,

Andy

https://support.checkpoint.com/results/sk/sk38848

https://support.checkpoint.com/results/sk/sk40090

[FtW64]

Hi Andy,

I have logging working, but I still see traffic from the RGW to the SMS (private IP address) on port 18264. This traffic does not make it over the Internet :-).

Frank

[the_rock]

As @AmirArama said, maybe run those captures mentioned and see what it gives. May provide some insight.

[AmirArama]

There are two points here:

1. The remote gw should know that he should access the mgmt server via its public nat ip, and not via its IP as configured in the policy. How can we do that?

If your remote gw is GAIA you should edit the masters file on the GW and override the name of the mgmt with the public IP of the mgmt. And make sure the file won't be overriden

https://support.checkpoint.com/results/sk/sk102712

if your remote gw is spark, at the management connection page there is a setting that overrides the mgmt IP with specific IP. Configure the public mgmt nat ip there.

2. The traffic flow should be translated from private to public ip and vice versa. How can you do that?

Configure manual static nat for outgoing from mgmt private ip to remote gw translate src to public. And 2nd rule from rgw ip to public nat ip translate dst to private IP.

Install both nat rules only on the local GW that the mgmt is behind it.

[FtW64]

Hi Amir,

Thanks for pointing me to the masters file (I totally forgot about this file, used it propably 15 years ago :-)).

Required NAT on the LGW is already in place (I can do policy installs to the RGW). Only issue is traffic initiated on the RGW destined to the SMS. A NAT rule for this on the RGW seems to be ignored.

I modified the masters file and made it immutable (prevent it from being overwritten by a policy install). I even did a cpstop;cpstart (after a policy install).

However, now I get a 'Local interface address spoofing' on the RGW when accessing the public IP address of the SMS (the one that I have configured in the masters file)... I set spoof protection on all interfaces (RGW) to 'Detect and Log', but that does not help (obviously, as this is a 'Local interface address spoofing' message.

I have no problem accessing any other public IP address from the RGW.

RGW is not a cluster.

[AmirArama]

Is it possible that you have routing loop and your outgoing traffic from the rgw is returned back to it by the next hop or maybe your rbw nat rule cause not valid behaviour (don't need it)

If that didn't help

Take tcpdump + fw ctl zdebug drop on the rbw while you replicate it and see what is going on

[FtW64]

Hi Amir,

Thanks for your help.

I rebuilt the configuration, modifying the masters file. For some reason it works fine now. To wrap up:

• Global Properties: disable 'Accept Control Connections'.
• Modified the masters file on the Remote GateWay to contain the public IP address of the SMS (and made it immutable).
• Static (manual) NAT rules for the SMS on the Local GateWay only.
• Required access rules (of course) on both gateways.

Pity there is no 'better way' to do this (don't really like the manual modification to the masters file).

[AmirArama]

As far as i know there is a plan to have that in smc configuration in next version/s without the need of masters file.

[_Val_]

Why would you disable "Accept Control Connections"?

[FtW64]

I was under the impression that if you enable 'Accept Control Connections', manual NAT from the SMS to RGW would not work. However, I cannot reproduce this (any more). So I guess, this is not really required after all. I have been trying a lot of setups, and perhaps I got a little bit confused :-).

[the_rock]

Just keep in mind below...

Andy

• Accept Control Connections is used for:
  • Installing the security policy from the Security Management server to the gateways
  • Sending logs from the gateways to the Security Management server
  • Communication between SmartConsole clients and the Security Management Server
  • Communications between Firewall daemons on different machines (Security Management Server, Security Gateway)
  • Connecting to OPSEC applications such as RADIUS and TACACS authentication servers

  If you disable Accept Control Connections and you want Check Point components to communicate with each other and with OPSEC components, you must explicitly allow these connections in the Rule Base.

  • Accept Remote Access control connections

    Accepts Remote Access connections when is Accept Control Connections enabled.

  • Accept SmartUpdate connections

    Accepts SmartUpdate connections.

  • Accept IPS-1 management connections

  Accepts IPS-1 connections. For more, see the IPS-1 Sensor Administration Guide.

• Accept outgoing packets originating from Gateway

  Accepts all packets from connections that originate at the Check Point Security Gateway.

  • Accept outgoing packets originating from Connectra gateway
  • Accept outgoing packets to Check Point online services

    Allow Security Gateways to access Check Point online services.