NAT Rule Number 0

[TheRealDiZ]

Hi Guys,

We got some weird issues with NAT on R80.20 (no hf installed).

When we check logs we notice that basically the traffic was hitting a rule called "NAT Rule Number 0".

What does it stands for?

I have tried to check NAT Rules/Objects/implied rules/global properties and I was not able to find anything related to it or anything related to NAT for that specific network/objects.

Let me know,

RealD!Z

[PhoneBoy · Accepted solution]

There is a special option on Gateway objects to hide all traffic behind its external IP.
Maybe that's it?

[Timothy_Hall]

Do you have a static NAT defined for your SMS object and this checkbox set:

Do you have this box set in the NAT properties of your gateway/cluster:

There are also some NAT Rule 0 elements involved with clusters and hiding outbound connections initiated from the firewall itself behind the cluster address...

[JozkoMrkvicka]

If you have cluster deployment and one of the members is the source of the traffic, then all outgoing traffic from cluster member is hiding behind cluster IP. This is the default behavior and in such a case you will see NAT rule number 0 doing "NAT" in log.

If this is the case, then you can read more about that here:

Outgoing connections from cluster members are sent with cluster Virtual IP address instead of member...

[TheRealDiZ]

Thank you guys ALL for the fb.

By the way this was the first setting I was looking for:

As you can see traffic still hitting NAT rule number 0 that is why I have posted to the community..

Anyone that has experienced this behavior?

[Maik]

I'm currently experiencing this issue with CP control traffic passing through the gateway [FW1_ica_services] from a third party management server. We also have the hiding option in the gateway object disabled, support case is open...
Btw, also running R80.20 but with jumbo hotfix take 47 and a custom hotfix on top of this one.

(Why is this thread marked as solved?)

[TheRealDiZ]

Hey @Maik ,

Thank you for your reply!!

The issue is not solved as mentioned in my previous post.

But my question answered by @PhoneBoyit is actually correct: NAT rule number 0 is the flagged option in the Security Gateway Object.

By the way can you just keep me posted on your case open with TAC?

You mentioned that you have currently installed take 47 and I'm assuming the issue is not solved at least up to this take.

I'm afraid of two things:

1. Rule is still matching  traffic in production and they do not have actually notice it... Let's say for example we patch the firewall with latest JHFA.. and the rule won't be matched anymore, I should worry about ALL the traffic that is hitting the rule and create eventually NAT rule where is needed...

2. We have installed R80.20.M2 on the Security Management Server.. It could be a cosmetic bug where a flag that is not flagged is actually applied?

That's huge and I'm very concern about both points...

[Maik]

We are running MDM R80.20, standard release. I don't think that this one is a cosmetic issue as this would depend on the SmartConsole application - and I guess if this check box "works in reverse" (unselected => selected and vide versa) a lot of people would have complained until this point.

Still - the interesting thing is when and why this issue happens.

I am not worried about any impact after is has been fixed as this issue just destroys legitimate traffic by also translating the destination port to TCP 0 [in my case the dst ip stays as the correct one and does not get translated, just the source IP + port and the destination port are getting ripped apart).

Did you try to create a excplicit "no-nat" rule for this traffic to see if it has any impact? I was not able to do this due to a different bug which kills almost all connections and VPN tunnels once a policy install gets initiated (ticket already opened...).

[TheRealDiZ]

I got your point, but in my case.. Someone maybe could have forgot to configure all the Hide NAT Rule needed to make thing works properly.

So if I solve the NAT rule number 0 in my case someone could experience issues with traffic that is actually natted with it.

I have to double check that everything is properly configured.

BTW I'm going to install latest Jumbo take for R80.20 and I will keep you posted with my findings.

[Maik]

To keep you updated; I am onsite again today and was finally able to collect the debugging information for TAC. Now I'm waiting for the results. Anything new from your side?

[TheRealDiZ]

Hey @Maik ,

On my side I have installed latest JHFA for R80.20 and no issues at all.

Btw I checked logs this morning and fortunately it seems there is NO MORE NAT RULE NUMBER 0 (except for packets orginating by the gateway itself)!!!!

I think this was a bug in a environment with a clean R80.20 without JHFA.

Now I can clearly see logs for http/https connections from client to Internet matching their own NAT rule.

D!Z

[sabil]

nice

[Maik]

Sounds good, thanks for the information! I received a TAC suggestion how the issue can be solved - but was not able to test it due to possible cluster failover / down time which is required for the change. Can post the suggestion when I am back in the office.
However; I asked the TAC engineer whether this is a known issue which would/already had been be fixed in an upcoming jumbo package (we have take 47 installed) and received the answer that it is possible but quite unlikely. So maybe we have a different problem - but the truth can be seen when I have updated to the latest jumbo take (and maybe tried the work around if the jumbo upgrade should not work/solve the issue).

[it-support]

Hello,

What was the solution for this issue, I currently have the same one on R80.20 take 118

Regards

[cosmos]

It's 2022, I'm running into this issue in R80.40 with a relatively recent hotfix. The traffic being translated is also FW1_ica_services from another gateway managed by a different domain, as well as FW1_ica_pull which resulted in failed attempts to upgrade/reconfigure a VSX cluster.

The issue started when the problematic VS was migrated from pre-r80 to the 80.40 cluster, that just happened to pass control traffic for the cluster being upgraded.

Sure I can work around it with a no-NAT rule, TAC case and hotfix but why is R80 making [incorrect] assumptions about other peoples stuff?

Day-O!

[cosmos]

For anyone else with the issue, sk178087 describes the behaviour, the solution is to comment out the entire hide_services_ports line in the relevant table.def for the manager & gateway combo.

It appears this change in behaviour snuck in before R80.40 HFA91 as it was not present on an unpatched 80.40 MDS/gateway combo. I don't see it in the release notes, I hope this was not to address a bug as it has caused nothing but problems for us.

Specific services still attempting to NAT over route-based VPN tunnel (checkpoint.com)

Cure worse than the diesase?