topic Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10 in Firewall and Security Management

Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Oliver_Fink — Mon, 29 Aug 2022 17:30:01 GMT

We upgraded one of our customers some time ago from R80.30 to R81.10 and experienced a lot of problems – and still have some serious ones to solve.

One of the problems is that automatic NAT for outgoing connections from virtual systems does not work anymore. Instead of the real IP addresses of the VS the Internal Communication Network addresses (aka "funny IPs") are used. Thus, no communication for VSes is possible without manual NAT rules.

We have a network design where several different VSes (VPN FW, LAN FW, DMZ FW and Webserver FW) are connected via a virtual switch to the same external network (means: Internet).

With R80.30 each of this VSes reached Internet with its real IP without implementing manual NAT rules. That does not work anymore with R81.10. TAC told us that we have to apply manual NAT rules as described in sk119304.

The same happens for internal connections connections to DNS and NTP servers etc.

My question is: Why did Check Point break automatic NAT in R81.10 making this version technical inferior to R80.30 regarding this point? What about usability when you have to apply manual NAT rules for any interface with traffic originating from a VS?

In my opinion that is not the maturity you would expect from enterprise grade software. It seems to be half-ready, banana software – ripes at the customer.

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

PhoneBoy — Mon, 29 Aug 2022 18:25:30 GMT

That SK suggests (by versions listed) this isn’t new behavior with R81.10…

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Chris_Atkinson — Tue, 30 Aug 2022 01:37:19 GMT

Similarly sk101448 describes some related scenarios, do either of those apply to your case?

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Ilya_Yusupov — Tue, 30 Aug 2022 05:23:37 GMT

hi @Oliver_Fink ,

I have VSX system in my lab with R81.10 JHF 66 and NAT is working with automatic rules.

I will contact you offline to get more info about your case and will try to assist.

Thanks,

Ilya

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

KostasGR — Tue, 30 Aug 2022 09:53:23 GMT

Hello @Oliver_Fink

If you have created a manual NO-NAT rule you must exclude from that the "funny ips" range.

BR,

Kostas

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Oliver_Fink — Tue, 30 Aug 2022 10:07:39 GMT

I know that the SK suggests that this is not new behaviour. But I can assure that it worked for years without manual NAT rules – with R80.30 and even with R77.30. And it stopped suddenly working after upgrading to R81.10.

Such I have to create manual NAT rules for every node's funny IP on every interface it communicates to (DNS, Identity Collector, Identity Sharing, Cloud Services, etc.). The customer wants to go from 2 cluster nodes to 4 or more nodes in the future. This would result in more NAT rules. Maybe I can workaround that with using funny IP network NAT rules instead of host rules for each node.

But I would expect that the VS sends traffic with its own real IP address and is able to communicate with "the world" – as it did before. Everything else is fiddling, not enterprise grade behaviour.

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Oliver_Fink — Tue, 30 Aug 2022 10:18:12 GMT

Thanks Chris.

That was a valuable hint. The VS I have in mind does not have any manual NAT rules. But the table.def file consists and has the content of:

no_hide_services_ports = { <4500,17>, <500, 17>, <259, 17>, <1701, 17>, <5500, 17>, <22, 6>
, <80, 6>, <444, 6>, <53, 17> };

I will test if HTTPS works without NAT rules and HTTP does not. That would confirm that it is table.def causing the issue.

I will come back with my results.

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Oliver_Fink — Tue, 30 Aug 2022 10:23:41 GMT

Thank you, Kosta.

Yes, I really wondered why that is not mentioned in the solution part of sk119304.

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Oliver_Fink — Tue, 30 Aug 2022 10:40:37 GMT

Contratulations, @Chris_Atkinson. What TAC did not find in several weeks of debugging – you discovered it in seconds!

If I remove the manual NAT rules, HTTP connections stop working and HTTPS still does. That seems to be a clear sign for me, that table.def configuration is the cause of the problem.

Now I wonder what changed with the interpretation of table.def between R80.30 and R81.10…

And I need a maintenance window at the customer to test what falls apart if I delete the last 4 entries from no_hide_services_ports. 😉

Thank you.

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Chris_Atkinson — Tue, 30 Aug 2022 12:57:03 GMT

Pleased to hear that you have a way forward now. 🙂

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Henrik_Noerr1 — Tue, 30 Aug 2022 14:47:14 GMT

Hey,

Regarding broken clusternode traffic, we saw it all break in r8040 and still is in r8110
https://supportcenter.checkpoint.com/supportcenter/portal?eventSubmit_doGoviewsolutiondetails=&solutionid=sk167453&partition=Advanced&product=ClusterXL

passive node sends traffic out through sync to active.
active is supossed to NAT all traffic but we see that it mostly doesnt. We are on 8110 take 55 and are aware of the kernel parameters possible to tweak this behaviour. Not a good solution.

/Henrik

Re: Why did Check Point break automatic NAT for outgoing connections from VSes in VSX R81.10

Henrik_Noerr1 — Tue, 30 Aug 2022 14:48:55 GMT

Furthermore passive node is not included in implied rules for the active node and is hence dropped if you do not make specific rules for all implied traffic