NAT problem

[GigaYang]

Due to certain reasons. The previous administrator set several manual NAT rules (Rule6~10) on the firewall.

We want the host 172.16.224.109 to connect to the Internet through the third External interface (WAN3) of the firewall. And we set a PBR as the default route of the host.

But because of the influence of Manual NAT rule rule9. This makes it impossible for us to directly set Hide NAT to allow the host to connect to the Internet. Instead, a manual Hide NAT rule (Rule5) must be added to this rule.

After adding the NAT rule of Rule5, 172.16.224.109 can already access the Internet. But the strange thing is that after adding the NAT rule, I have to wait for several minutes before I can connect to the Internet. And when we remove the NAT, we have to wait for a few minutes before the connection is disconnected.

Wondering if anyone else has encountered a similar situation?

[the_rock]

I recall customer having similar issue once and they just clearned NAT table, waited few mins, then all worked fine.

Andy

fw tab -t fwx_alloc -x from expert mode

[GigaYang]

Thanks for your kindly reply.

May I ask under what circumstances do we need to manually clear the NAT Cache? And will other service connections be affected when manually cleaned up?

[the_rock]

Make sure to do it in maintenance mode, as any connections having to do with NAT, would be disrupted.

Andy

[Timothy_Hall · Accepted solution]

Existing connections that are NATted will keep using the same NAT, even if policy is reinstalled with rules specifying a different NAT address/rule for that connection.  The NAT address to use is determined right after the Firewall/Network policy accept of the first packet and cannot be changed for the life of the connection.  Only newly-initiated connections will use the newer rule. 

What is probably happening is your DNS servers are sending DNS UDP requests to an ISP forwarder, which is tracked as a "connection" by the firewall.  Even if you change the NAT rule and reinstall policy all those packets will still have the old NAT applied until the DNS "connection" ends and a new one starts.  This would be a use case for clearing the NAT table as described earlier in the thread.  

A better way to do this without deleting more than necessary is to add a new SAM rule matching the connection attributes in the SmartView Monitor (or fw sam) and making sure "close connections" is set.  Simply apply the SAM rule, then immediately remove it to force new connections (with the new NAT) to start.

[GigaYang]

After add SAM rule. The traffic will be correctly applied to the new NAT settings.

But is this problem possibly caused by too much content in the NAT Table? I have never encountered similar problems when setting Manual NAT rules on other Checkpoint firewalls.

We checked the device status and the memory usage is not high.

[the_rock]

That is why I mentioned clearing NAT table would not be a bad idea.

Andy