fw monitor not filtering

[Johannes_Schoen]

Hi community,

I have some problems with monitoring devices through an vpn tunnel.
I used

fw monitor -e "accept( host(<ip>));"
fw monitor e ‘(accept src=<ip>);'

but I got the whole traffic - the filter is not working.

Is that maybe one of the nice bugs of R80.20?
Currently I'm on JHF73 because Check Point shredded my IA.

Looking forward to your suggestions

Best Regards
Johannes

[Maarten_Sjouw]

Maybe you can try without the extra ( ) like:
fw monitor -e "accept host(10.10.10.10);" -m iO

[NickGriffiths]

I've just highlighted this in here too: https://community.checkpoint.com/t5/Product-Announcements/R80-20-Jumbo-Hotfix-Accumulator-New-Ongoin...

Regardless of SecureXL status, T73 appears to have broken the filters.

[Johannes_Schoen]

@Nick thanks for your reply, another wonderful bug in the CP world.
I guess it can only get better from now on

[Johannes_Schoen]

Hi @opal, didn't work, it's the same.

[G_W_Albrecht]

I am sorry, but i really do not understand what you want to achieve here. Check Point's FW Monitor is a powerful built-in tool for capturing network traffic at the packet level. For monitoring devices for health, traffic rate a.o. most customers use SMNP !

fw monitor filters are using a subset of CheckPoints old INSPECT syntax to specify the packets to be captured. Details concerning functionality,  syntax a.o. can be found in How to use FW Monitor and in How to use FW Monitor.

[Johannes_Schoen]

@G_W_Albrecht: sry, I didn't explian myself from the beginning on.
Monitoring the cluster nodes with SNMP stopped working and I wanted to make sure, that the SNMP packets are passing the firewall.
Unfortunately the filters are broken (T-73) - maybe my monitoring problem is based on similar hotfix issues....

[Nick_Doropoulos]

Hi Johannes,

Specifying just the host/source ip address is still bound to overwhelm you with a great deal of output, depending on the services that the host in question uses and the traffic it generates in general.

I think the best way forward would be for you to tell us the following:

1. What is it exactly you are trying to achieve?
2. Is the host in question on your site or on the remote site?
3. What is exactly the traffic you are really interested in?
4. What interface did you run the fw monitor command on?
5. Did you turn securexl off before running the command? Remember that you don't have to do that on R80.20.

Many thanks.

[NickGriffiths]

The post that I made regarding the fw monitor filter being broken by JHFA T73 appears to have disappeared from the 'official' ongoing T73 thread. (The thread itself has been deleted).

I assume this means that a retraction of T73 is about to be made, functionality of fw monitor has been broken, and it will soon be replaced by a new ongoing take.

The symptoms of the OP match my findings, e.g. filters not being applied correctly/at all post upgrade to T73; but fine in T47.

[PhoneBoy]

Did you open a TAC ticket on this?

[Johannes_Schoen]

No, I haven't opened up a TAC case.

The expression-thing seems to be known and is one of many recently experienced bugs.

Regarding the strange SNMP behavior: I first need more time to exclude other issues.

[Johannes_Schoen]

Dear Nico, I think it's a bug with JHF-73 - filtering the traffic with the stated expression should work as expected.

[Martin_Schagerl]

take74 still shows the issue

[Scott_Paisley]

Take 87 also seems to have the same issue

[Matt_Killeen · Accepted solution]

FROM sk30583

fw monitor -F "{src IP}, {src port}, {dst IP}, {dst port}, {protocol num}"

Filtering the packets based on IP/port/protocol.
Notes:

• Value 0 is used as "any".
• Up to 5 filters are supported. Multiple filters are applied on packets in OR logical manner.

Note: Relevant for R80.20 from Jumbo Hotfix Accumulator for R80.20 (Take 73)

examples using fw monitor -F "{src IP}, {src port}, {dst IP}, {dst port}, {protocol num}":

fw monitor -F "0, 0, 0, 443, 0"

fw monitor -F "0, 0, 2.2.2.2, 0, 0"

fw monitor -F "1.1.1.1, 0, 2.2.2.2, 443, 0"

example for all DNS traffic which also captures all return traffic from DNS

fw monitor -F "0, 0, 0, 53, 0" -F "0, 53, 0, 0, 0" -w

I believe you need -w for full packet length capture and can still use -o to output files.

There is also a fw monitor -U to set fw monitor back to defaults. It appears to unload the monitor but not really sure what that does - I'm still testing the syntax and searching for more detailed documentation.

[Johannes_Schoen]

Thanks @Matt_Killeen for the update.
The old fw monitor was so hard to use, this new syntax is so innovative and ease to use.
Why use -e 'accept src(1.2.3.4)', when it's so much easier to use -F "1.2.3.4, 0, 0, 0, 0"
I want to get the pills or the stuff to smoke, the product management obviously got....

I mean we can be glad, the we are allowed to use IPs and no hex-stuff

[Danny]

@Johannes_Schoen ,

I'm working to make using FW Monitor to be the easiest experience ever. Just follow my work progress @ FW Monitor SuperTool.

[ChammiK]

This seems to be a really nice tool to use. I am a bit skeptical about SecureXL getting disabled though. The gateway is under a bit of load at the moment.

However, this doesn't help me with my problem at hand. I have the filters and syntax correct but I'm only seeing a single inspection point in the firewall chain no matter what I do. Got a TAC case opened for this. Was just wondering if anyone successfully used fw monitor to capture all inspection points in R80.20 JHF take 87+

[Danny]

If you're at R80.20 JHF take 87+ SecureXL won't be disabled by FW Monitor SuperTool. Also if your gateway is under load and you are using an older version you should disable SecureXL only for the IP addresses to be monitored. This has to be done on the management though.

[Johannes_Schoen]

@Danny: Thanks for the input, I was not aware of this.
Would be cool, to have this as an onboard-support tool

[Anthony_Kahwati]

Hi... thanks for this all

I've just tried this

fw monitor -F "1.2.3.4,0,0,0,0"

And it still isnt filtering. I am running on R80.20 Take103. Am I doing something obviously wrong here?

Also wondering, does anyone know the alternative for the 'accept host(....);' version? i.e. not defining whether source or destination?

[Timothy_Hall]

Do not use quotes or any type of wildcard character for your filter, they will be interpreted as a syntax error and you'll get an unfiltered capture.  The equivalent of host(1.2.3.4) for fw monitor -F is the following (multiple -F options will be ORed together, not AND):

fw monitor -F 1.2.3.4,0,0,0,0 -F 0,0,1.2.3.4,0,0

As discussed in my "Max Capture: Know Your Packets" video series, you may want to load the cppcap tool onto R80.20 if you have complex filtering requirements, as fw monitor -F is very limited and borderline dangerous if you make a filtering syntax error on a busy firewall.  cppcap can capture accelerated traffic and is designed to limit the performance impact imposed on the firewall when it is running.  See my 2021 CPX Presentation for more information about cppcap and Check Point packet captures in general.

[ChammiK]

Does this show you all the inspection points? I tried this with -p all but it only shows me a single position in the inbound chain. What I need to see is the interface that the traffic is going out of.

[Marco_Valenti]

Just want to brought this to your attention https://tcpdump101.com/# was updated with the -F syntax for fw monitor , thanks grave_rose for that

[Hugo_vd_Kooij]

I have an odd issue with a R81.10 gateway where I can only see traffic one way.

I used `fw monitor -F 10.3.2.1,0,0,0,0 -F 0,0,10.3.2.1,0,0 as I always do bu t I can only see traffic FROM the client. The output seems to indicate nothing is compiled for traffic TO the client.

Swapping the 2 -F options has no impact. 

I must admit I haven't seen this behavious before.

I checked with tcpdump on the client facing interface that the traffic indeed passes the firewall in both ways.

[Timothy_Hall]

Model and code level?  Using UPPAK?

[Bob_Zimmerman]

Is NAT involved? These filters match packets, not flows, so your filter for the return traffic needs to match how it arrives at the firewall.