Destination port NAT on gateway main IP

paver · ‎2019-03-13

I did a migration earlier this week from ScreenOS to Check Point where VIP IP's were used to do an incoming port NAT to multiple DMZ servers.
I have my security policy configured to allow incoming traffic to the gateway object on port 5522.
The NAT rule translates the the public gateway IP towards the real DMZ server IP and target port 22.
In the logs I see my traffic being accepted and the destination NAT IP and port is correctly applied but it is not working, a fw monitor only shows me this (filter on the source IP only) where x.x.x.x is the incoming public IP and y.y.y.y is the firewall main IP (public).

[vs_1][fw_1] eth1.10:id[52]: x.x.x.x -> y.y.y.y (TCP) len=52 id=12511
TCP: 34019 -> 5522 .S.... seq=f44543c0 ack=00000000

A 'fw ctl zdebug drop' does not show any drop.
I also tried to add the gateway object as original destination in the NAT policy, when I do this the NAT is not correctly applied.

Global properties has NAT set to NAT destination on client side for manual and automatic NAT.

No helpful sk our CheckMates article found on this subject/behavior.

Maarten_Sjouw · ‎2019-03-13

You state you have 5522 allowed, also allow port 22 and the VIP plus the NATted IP as destination, now it will allow the traffic to the VIP on 5522 but it will not allow the traffic to the server on port 22.

Keep in mind NAT rules are not access rules.

Regards, Maarten

paver · ‎2019-03-13

This doesn't make sense, I should not add a rule to allow traffic to the private IP and real port from internet.
See https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solut...
and destination NAT on client side.
The security policy match is only done on the public IP and port 5522 in my case, once accepted the NAT is done and traffic is routed out to the real IP and port, not?

In any case, just to be sure of my findings I tested your advise and this makes no difference, still the same behavior.

Jerry · ‎2019-03-14

see below, you should be fine after getting through those threeds 🙂

https://community.checkpoint.com/t5/General-Topics/NAT-on-ClusterXL-in-HA-mode/td-p/16051

https://community.checkpoint.com/t5/General-Topics/clusterxl-vmac-and-proxy-arp/td-p/37424

let us know if you won't, I'm happy to dig it a little bit more but first of all, would you mind providing us one little thing as of evidence what we are actually referring to?

cpinfo -y all

Jerry

Maarten_Sjouw · ‎2019-03-14

Not quite true, there is a FW process in the inbound and one in the outbound chain, look with fw ctl chain to see the processes in each chain.

When you use Automatic NAT, the object contains the external IP and the internal IP in the same object.

As you are doing a manual NAT and PAT, the traffic will be checked in the outbound chain as well.

Regards, Maarten

paver · ‎2019-03-14

Thanks for the feedback so far but none of the provided articles is helpful.
I already configured many times destination NAT on a Check Point but never used the gateway main IP as a destination and do port NAT for this one.

This is a manual static NAT for which I would not need to configure static proxy-ARP since it is the gateway IP itself.
Also since I see the traffic properly arriving on the gateway this part is fine.

The setup is a VSX cluster with a VS0 and VS1 where VS1 is the internet facing gateway, my VS1 cluster object has as main IP the public IP configured which is used in the manual static destination NAT.

Management is running R80.20.M2 and the gateways R80.20 + jumbo #33, please find below the cpinfo -y all:

[Expert@GW01:0]# cpinfo -y all

This is Check Point CPinfo Build 914000182 for GAIA
[IDA]
No hotfixes..

[CPFC]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

[MGMT]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

[FW1]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

FW1 build number:
This is Check Point's software version R80.20 - Build 026
kernel: R80.20 - Build 022

[SecurePlatform]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

[CPinfo]
No hotfixes..

[DIAG]
No hotfixes..

[PPACK]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

[CVPN]
HOTFIX_R80_20_JUMBO_HF_MAIN Take: 33

[CPUpdates]
BUNDLE_R80_20_JUMBO_HF_MAIN Take: 33

[rtm]
No hotfixes..

Regards,
Pascal

paver · ‎2019-03-14