Confused by Manual NAT Rules - kindly asking for clarification

[Georg_Schwarz]

Inclined Readers,

This is my first post on Checkmates, I have done my best to find an answer, to no avail... I am afraid there is a misconception on my side.
However, if I am in violation of any rules explicitly stated or unwritten, my apologies beforehand...

My Question is concerning NAT-rules. We are replacing a lot of our customer's old Linux-based iptables Firewalls with Checkpoint 700 and 1400s. One of the common scenarios is that multiple servers are published using different public IPs.

As I was experiencing Problems with the Proxy ARP Checkbox in the GUI on some Firmware versions, I have most times manually edited the local.arp file and used manual NAT rules to get my stuff done. I checked this with Checkpoint support, and the gave me the go-ahead for this procedure.

However, what strikes me is that although I can use Manual NAT rules for all additional IPs, manual NAT rules for the boxes 'Primary' IP (the one shown on the Internet Connection) are completely ignored, and I will again have to use the New Server wizard. Mixing both of these approaches seems extremely inelegant, but for me it now seems to be the only way to get things working. I just ran into it agian on a box with R77.20.85 installed...

In fact, I would be really pleased if I could only just create manual NAT rules and matching access Policy rules - I guess it kinda makes me feel at home with the PREROUTING and FORWARD chains of iptables. 😉

My Questions in particular are:

- Am I getting something wrong here, or is this behavior by Default?

- Is there anything I could do to make a 700/1400 Gateway work in a way that I can work without the Publsih Server wizard?

The only thing I relating to that behavior I have found in the documentation (ApplianceLocalAdminGuide) of the Small Business series is:

If servers with NAT are configured, the manual NAT rules do not apply to them. However, they apply even when Hide NAT is activated. 

To me this can mean anything. What I have oserved so far is that the behavior is that even when I have no servers defined, the manual NAT rules on the Primary IP are just being ignored...

Well People thank you for reading the entire post, I did not know how to use fewer words.

Thanks in Advance

George

ADDITIONAL INFORMATION (For those who really like to read Long stories)

- The Screenshot shows a manual NAT rule that Redirects traffic to a Linux Server with its own Firewall that only accepts packets from the local Network. The rule only works if the translated Destination object is shown as a Server... (And I can only create this one by the New Server Wizard, including the autogenerated-rule which I cancel out by my manual rule anyway).

If I just create the same rule without the New Server wizard and use an Single-IP-Object that I created, it doesn't work… However if I do the same config on an proxy-ARPed IP (entered in local.arp) it works like  charm *headscratch*

The Hide NAT INTERNAL_IP object is just here to make the packet appear from the SG, tricking the Server into thinking its from the local Network...

[PhoneBoy]

Is there a specific reason you want to use Manual NAT rules versus the Publish Server wizard?

Or specific functionality that you want that you can’t get with the Publish Server wizard?

Sounds like it’s merely personal preference (which I understand).

I’ll have to see if what you’re experiencing is expected behavior or not.

[Georg_Schwarz]

Hi!
First of all thanks for your answer, very much appreciated!

My problem ist that if I try to DNAT a service using an additional external IP (which we have in most cases), I would have to do it exactly the other way round.
To make sure, I just re-tried that on a 750 running R77.20.75, and when I check the Proxy-Arp checkbox in the server-wizard it does not do anything. (Just seeing ARP requests in tcpdump in expert mode but no replies from the SGW)
So I have to go to expert mode, modify the $FWDIR/conf/arp.local and create manual NAT rules with single IP objects. (Because then, with additional IPs, the server wizard will not produce a working rule)

I also observed when using the "Force translated traffic to return to the gateway"  checkbox on the wizard the resulting rule displays a correct Hide NAT setting in the translated Source column of the automatic rule, but that setting does not have any effect, and I would yet again have to create a manual NAT rule.
(just verified it on a R77.20.85 a couple of mins ago)

So based on these observations I thought it might be a good idea to leave aside all the wizards, and have one unified way to do things (as there are multiple support technicians maintaining these babies, we'd like to have kinda self-evident SOPs in place)
But as it looks now, we have to use manual NAT rules for DNATs on the additional IPs and the Server objects plus auto-generated rules for the main IP... And this is hard to explain, and even harder to cast into a SOP 😉

I am still not sure, whether I am running in some of webinterface quirk or if I am getting something fundamentally wrong...

Thx for reading my lamentations
Best, George

P.S.: And yeah, I still love these boxes, because they are just 'linuxy' enough to make me feel being in control of the packets

[PhoneBoy]

It's entirely possible we have different underlying mechanisms for "this gateway" versus other IPs.

I know when I use SMB appliances in a centrally managed way, I can configure manual NAT rules for "this gateway."

[HristoGrigorov]

Have you tried to use gateway's actual IP instead of "This Gateway" object ?

[Georg_Schwarz]

Yeah just tried that, didn't work. The NAT functionality itself seems to be somehow linked with the server object. When I am doing a tcpdump (or fw mon) I can see that the packets disapper on the SGW. However when working with an additional IP, the rule works for some magic reason…

Thanks for the Suggestion, much aprreciated!

George

[HristoGrigorov]

I think you might be running into one of the limitations of a locally managed appliance. From my experience if you want to utilize their full potential you need the central management. Not that what you are trying to achieve is complex but just the WebUI often limits you. May be if you try to do it through CLI shell it will work better?