Smart Console: Packet Mode - Possible Bug?

[Maik]

Hello guys,

Yesterday I stumbled upon a bug with the packet mode search option within the Smart Console. At least I think that the seen behaviour is a bug, because related to Check Point the Packet Mode provides the following feature:

"This is a search mode that searches through a security policy as if a packet is traveling through it."

So to start in the beginning, I was creating a host network object which has multiple interfaces, therefore I provided one address via the General tab of the object and the secondary one via the Network Management tab. For the purpose of sharing the information here I made the most part of the related host (let's just call him "p1") unreadable:

The primary IP is XXX.XXX.XX4.111:

 

The secondary IP is XXX.XXX.123.1/24

Now the interesting part that came into my mind, is the option of a subnetmask for the secondary IP. Usually I specifiy it simply via a "/32" in order to specificly address the single host IP. But I was wondering what would happen if you specify the real networks subnetmask - so a /24 instead of the /32 in my case.

So I did exactly that and tried several things via the packet mode search, after creating the rule as seen below:

First test:

Mode: Packet

Source: Made up source IP (any specified in the rule)

Destination: Primary IP of the "p1" object => XXX.XXX.XX4.111

==> Matches rule 63 from the screenshot above, this is absolutely fine and correct

Second test:

Mode: Packet

Source: Made up source IP (any specified in the rule)

Destination: Secondary IP of the "p1" object => XXX.XXX.123.1

==> Matches rule 63 from the screenshot above, this is absolutely fine and correct

Third test (search string from the rulebase screenshot):

Mode: Packet

Source: Made up source IP (any specified in the rule)

Destination: A random IP in the subnet of the secondary IP of the "p1" object => XXX.XXX.123.10 (note the 10 in the fourth octett!)

==> Matches rule 63 from the screenshot above, this is got me to the point where I became really unsure about the packet matching process. Because in my opinion this should not match at all.

So I verified all the cases via fw monitor (sourced from the firewall as I had no host to test at that point). Test one and two were absolutely fine, the packets went trough the firewall, the packets went through pre and post outbound all was perfect. Afterwards I tried the third case:

admin@MY_FW_NAME:~# telnet XXX.XXX.123.10 30800
Trying XXX.XXX.123.10...

admin@MY_FW_NAME:~# fw monitor -e "accept dst=XXX.XXX.123.10;"
monitor: getting filter (from command line)
monitor: compiling
monitorfilter:
Compiled OK.
monitor: loading
monitor: monitoring (control-C to stop)
[vs_0][fw_24] bond1.3963:o[60]: 10.XX.2X4.62 -> XXX.XXX.123.10 (TCP) len=60 id=43637
TCP: 34046 -> 30800 .S.... seq=2bdf4aa3 ack=00000000
[vs_0][fw_24] bond1.3963:o[60]: 10.XX.2X4.62 -> XXX.XXX.123.10 (TCP) len=60 id=43638
TCP: 34046 -> 30800 .S.... seq=2bdf4aa3 ack=00000000
[vs_0][fw_24] bond1.3963:o[60]: 10.XX.2X4.62 -> XXX.XXX.123.10 (TCP) len=60 id=43639
TCP: 34046 -> 30800 .S.... seq=2bdf4aa3 ack=00000000
[vs_0][fw_24] bond1.3963:o[60]: 10.XX.2X4.62 -> XXX.XXX.123.10 (TCP) len=60 id=43640
TCP: 34046 -> 30800 .S.... seq=2bdf4aa3 ack=00000000
monitor: caught sig 2
monitor: unloading

This time the packets were dropped and did not reach the post outbound inspection point at all. That gave me a relief as I thought, at least for a short time, that you specify whole networks by mentioning a host IP with a subnetmask not equal to 32 in the Network Management tab.

So long story short; the packet mode reads secondary IPs [from interface objects] within host objects with a networkmask based match while the actual firewall only reads the specified address and ignores the subnetmask. For the firewall it always seems to be a /32 - even if you specify a /24 or something different. That results in differents outcomes related to the actual packet processing and the packet mode.

Is this expected? If yes, why? I thought that the packet mode matches firewall packet handling 1:1, so that you can verify if specific traffic is allowed or not.

Regards,

Maik

[JozkoMrkvicka]

What will happen if you choose /32 IP within Network Management tab ?

What is reason for drop ? fw ctl zdebug drop

What in case you will create /24 subnet and add /32 as secondary IP ?

[Maik]

What will happen if you choose /32 IP within Network Management tab?

=> The host will be matched "exactly", so you will just see that the single /32 IP matches via packet mode and on the firewall itself.

What is reason for drop ? fw ctl zdebug drop

=> Did not test that, I just used fw monitor to make sure it is getting dropped (should be getting dropped due to not matching any rule ~ implicit deny)

What in case you will create /24 subnet and add /32 as secondary IP ?

=> Not sure what you exactly mean with that question. A secondary IP with a /32 mask matches exactly, so just the given address will match via the packet mode. And if you specify a /24 but a host Ip within this network (1.2.3.4/24) the whole 1.2.3.0/24 network is matched via packet mode.

[Dmitry_Krupnik]

Hello Maik,

Thank you for this detailed investigation, let me check it internally. I will keep you updated.

Regards,
Dmitry Krupnik

[Dmitry_Krupnik]

Hello Maik,

After my investigation I can summarize:

1) This issue (showing incorrect rule as result of searching) isn't related to the Packet Mode. I have reproduce it also in the "general" mode.

2) I confirm, that this is searching issue only, not related to GW's action. Traffic is passed as expected.

3) I totally agree with you, the interfaces' netmask of the "Host" object should be automatically set as /32.

If the netmask won't be requested in the “Network Management” section of the Host’s settings it help us to avoid the issue, which you described. Also I think, that the “Network Management” section should be renamed for this object. The task related to these changes was opened, we are investigating the search issue and evaluating the changes in network management. When we will have final decision about this task, I let you know result. 

Thank you very much for feedback and detailed investigation, we appreciate your assistance.

Regards,
Dmitry

[Dmitry_Krupnik]

Hello Maik,

I am pleased to inform you, that RnD agree with our suggestion, that interfaces' netmask of the "Host" object should be automatically set as /32. They will have a big project later this year regarding topology, this task was documented and we will be back to this during project's effort.

Regards,
Dmitry

[Maik]

Great to know, thanks for the information