Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
Oliver_Fink
Advisor
Advisor
Jump to solution

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

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.

1 Solution

Accepted Solutions
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE

View solution in original post

11 Replies
PhoneBoy
Admin
Admin

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

0 Kudos
Oliver_Fink
Advisor
Advisor

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. 

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
Oliver_Fink
Advisor
Advisor

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.

0 Kudos
Oliver_Fink
Advisor
Advisor

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.

0 Kudos
Chris_Atkinson
Employee Employee
Employee

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

CCSM R77/R80/ELITE
Ilya_Yusupov
Employee
Employee

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 

KostasGR
Advisor

Hello @Oliver_Fink 

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

BR,

Kostas

 

 

0 Kudos
Oliver_Fink
Advisor
Advisor

Thank you, Kosta.

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

0 Kudos
Henrik_Noerr1
Advisor

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=&solut...

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

0 Kudos
Henrik_Noerr1
Advisor

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

0 Kudos

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events