Some connections show XLATE NAT, some are not

[Equipe_reseau]

Hi,

We have a connection flow 40.114.238.127 > 10.162.20.38 or 10.162.20.39 port 10048.

When i check traffic log, some connections show XLATE NAT. But some are not showing, even though all connections are accepted.

You can check below:

[Equipe_reseau]

Could someone explain why we can not see XLATE NAT on some connections ? Are they normal or abnormal ?

If abnormal, how can we fix it ?

Thanks in advance.

[Timothy_Hall]

Please post the full log card with all sections exposed of one log entry that is showing NAT in the columnar output, and another log card that is not.  Please redact identifying IP addresses as needed.  It may be due to Session Logging but it looks like all of those are Connection-based logs.

[Equipe_reseau]

Hi Timothy,

I am not sure if below is full log cards you need.

an example log With Xlate NAT:

an example log Without Xlate NAT:

If they are not full log cards you need, so could you please tell me how to get them ?

Thanks in advance.

[Timothy_Hall]

Hmm it is almost like those logs are duplicates of each other, however they are two unique logs generated by the gateway due to the unique Id and Sequence Number under More, almost like you have both Session Logging and Connection Logging set for that rule due to the presence of the Session tab.  In your rulebase please right-click the Track column of rule 107 and select More, then post a screenshot of your Track and Log Generation options for that rule.  These somewhat hidden Log Generation options are the subject of my 2022 CPX speech called "Max Gander: The Hidden World of Log Generation and Log Suppression on Check Point".

I'm also going to loop in @Vladimir here for his opinion as this is similar to another situation we were discussing recently.

[Vladimir]

@Timothy_Hall , thank you for looping me in. Definitely something to look into.  @Equipe_reseau , can you tell us what version and JHFA you are running and if NAT Templates are enabled ('fwaccel stat' output)?

[Equipe_reseau]

Hello @Vladimir ,

Here is the result:

[Expert@#####]# cpinfo -y all

This is Check Point CPinfo Build 914000227 for GAIA
[CPFC]
HOTFIX_R80_30_GOGO_JHF_MAIN Take: 236
[MGMT]
No hotfixes..
[IDA]
No hotfixes..
[FW1]
HOTFIX_MAAS_TUNNEL_AUTOUPDATE
HOTFIX_R80_30_GOGO_JHF_MAIN Take: 236

FW1 build number:
This is Check Point's software version R80.30 - Build 240
kernel: R80.30 - Build 250
[SecurePlatform]
HOTFIX_R80_30_GOGO_JHF_MAIN Take: 236
[CPinfo]
No hotfixes..
[PPACK]
HOTFIX_R80_30_GOGO_JHF_MAIN Take: 236
[CVPN]
HOTFIX_R80_30_GOGO_JHF_MAIN Take: 236
[CPUpdates]
BUNDLE_CPSDC_AUTOUPDATE Take: 19
BUNDLE_INFRA_AUTOUPDATE Take: 52
BUNDLE_DEP_INSTALLER_AUTOUPDATE Take: 23
BUNDLE_HCP_AUTOUPDATE Take: 48
BUNDLE_MAAS_TUNNEL_AUTOUPDATE Take: 61
BUNDLE_R80_30_JUMBO_HF_MAIN_3_10_GW Take: 236
[CPDepInst]
No hotfixes..
[AutoUpdater]
No hotfixes..
[hcp_wrapper]
HOTFIX_HCP_AUTOUPDATE
[DIAG]
No hotfixes..
[cpsdc_wrapper]
HOTFIX_CPSDC_AUTOUPDATE

[Expert@###:0]# fwaccel stat
+-----------------------------------------------------------------------------+
|Id|Name |Status |Interfaces |Features |
+-----------------------------------------------------------------------------+
|0 |SND |enabled |eth0,eth1,enP1p0s2, |
| | | |enP2p0s2 |Acceleration,Cryptography |
| | | | |Crypto: Tunnel,UDPEncap,MD5, |
| | | | |SHA1,NULL,3DES,DES,CAST, |
| | | | |CAST-40,AES-128,AES-256,ESP, |
| | | | |LinkSelection,DynamicVPN, |
| | | | |NatTraversal,AES-XCBC,SHA256, |
| | | | |SHA384 |
+-----------------------------------------------------------------------------+

Accept Templates : enabled
Drop Templates : disabled
NAT Templates : enabled

Thanks for your kind support.

Regards,

[Equipe_reseau]

Hi @Timothy_Hall 

Please check below 🙂

Regards,

[Equipe_reseau]

Hi @Timothy_Hall 

Yes, on our traffic logs, we could observe both Session logs and Connection logs as below.

But the problem here is that Xlate NAT is showing on some Connection logs, and others are not 😞 we dont know if it is a Checkpoint issue (which could cause real connection issue) or it is a normal behavior.

Regards,

[Vladimir]

@Equipe_reseau , I see that the log containing NAT data is also listing Source and destination zones, whereas the log without NAT data, does not contain zone information.

If I have to venture a guess, this is a "router on a stick" implementation and the connection is being logged twice. Not sure if it is intended behavior though. Can you check to see if the Interface filter is enabled in the log view, remove it and post another screenshot? Also, and I am not sure if it is material, the General and Advanced properties of your TCP-10048 service.

[Equipe_reseau]

Hi @Vladimir ,

Since the beginning, we have not enabled interface filter on our log view.

Below is General and Advanced for our TCP-10048 service.

Regards,

[Timothy_Hall]

Nice catch @Vladimir on the zone information being in one log card and not the other.  Definitely possible in a router on a stick implementation.

However Vladimir's question about NAT Templates bugged me a bit and after staring at the two log cards for way too long here is what may be happening (which may possibly explain the lack of NAT information in Session-based logs too).  Bear with me here...

In R80.10 and earlier NAT Templates were not enabled, but if they were the sim/SecureXL driver would form NAT Templates (and also of course Accept Templates) by observing traffic leaving the firewall outbound through the sim driver after the initial packet of a new connection went through the inbound side of sim and up into F2F for a rulebase lookup.  Obviously if the packet was dropped no templates would form. 

However if the packet was allowed by F2F SecureXL would compare what the packet looked like on the inbound side of sim and the outbound side of sim to form NAT Templates (and Accept Templates) directly in SecureXL.  Future new connections requiring NAT that matched an Accept Template could also match a NAT Template thus avoiding a F2F trip for a NAT rulebase lookup on a worker.

However note here that SecureXL NAT Templates are not formed by a NAT rulebase lookup, just by observing traffic that passed completely through F2F and back into sim.  Contrast this with a cache hit against the separate NAT rulebase caching mechanism on the worker called fwx_cache; that table includes the NAT rule number right in the cache table as detailed in the third edition of my book where I do a poor man's NAT hit count trick on page 301-302.  Obviously with a full-fledged NAT rulebase lookup on the worker due to an fwx_cache miss the matching NAT rule number(s) will be known as well.

So here is the crux of the issue: if a new connection matches against a NAT Template how the heck does it know what NAT rule number was matched?  I don't think there is any way to know that at the sim/SecureXL level, which is why the "NAT" section is not being shown for some of your log entries; those matched a NAT Template.  The packets that matched a cached entry in fwx_cache or a full NAT rule base lookup will of course have the NAT log information present.

However in R80.20+ the initial creation of Accept/NAT templates was shifted from the sim driver up into the workers, BUT those templates are still offloaded back into sim/SecureXL for implementation, and the old limitation of not knowing the NAT rule number might still be there.  So Vladimir perhaps the NAT information is not included in pure Session logs because not all the similar connections that were rolled up had NAT information present due to partial NAT template matching, so it just leaves it out completely?

I'll admit I'm stretching here but this could be tested pretty easily by just turning NAT Templates off and making sure to start a NEW connection and see what happens with the NAT logging, even with only Session Logging enabled.  May even want to disable NAT Templates permanently and reboot the entire firewall before testing just to be sure, since "disabling" SecureXL in R80.20+ isn't what it used to be.

[Vladimir]

@Timothy_Hall , since I am testing in my lab and it is not a router on a stick, there is no one-to-one correlation, but so far, no dice: with NAT templates disabled:

[Expert@CPCM1:0]# fwaccel stat
+---------------------------------------------------------------------------------+
|Id|Name |Status |Interfaces |Features |
+---------------------------------------------------------------------------------+
|0 |SND |enabled |eth0,eth1,eth2,eth3,eth4,|Acceleration,Cryptography |
| | | |eth5 | |
| | | | |Crypto: Tunnel,UDPEncap,MD5, |
| | | | |SHA1,3DES,DES,AES-128,AES-256,|
| | | | |ESP,LinkSelection,DynamicVPN, |
| | | | |NatTraversal,AES-XCBC,SHA256, |
| | | | |SHA384,SHA512 |
+---------------------------------------------------------------------------------+

Accept Templates : enabled
Drop Templates : disabled
NAT Templates : disabled by user
[Expert@CPCM1:0]#

...rebooted and made active cluster member.

Firewall sessions do not contain NAT data. (deleted mention of no Firewall sessions being logged, took longer to show up in the log than I expected.)

When connections are logged, they do contain NAT data, but that was the case before NAT templates were disabled.

The APCL/URLF sessions are also present in the logs, but do not contain NAT data.

[Timothy_Hall]

Well so much for that theory involving NAT Templates, probably time for a TAC case unless Vladimir has any other ideas.

[Vladimir]

@Timothy_Hall and @Equipe_reseau . I suspect that this particular issue, i.e. seemingly identical connection logs with and without NAT are the result of the combination of 'router on a stick' and the rule's destination specified as Firewall's External. By the way, what is in the Source field of that rule?

Not sure how Azure is handling the traffic in the buffer zone between firewall's interface and the next hop, but it is entirely possible for FW to see the packet on its way out reflected to eth0, accept and log it, as per rule's structure.

I further suspect, that if you want to see only accurately processed packets in the logs, you may have to suppress logging on that rule (or limit it to firewall sessions, which will not contain NAT data) and add an additional one with the same service and the destination being 10.162.20.0/24 (or whatever your destination network is.

...or TAC it and please keep us updated.