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