CLI command to see a rule number if logging is not enabled.

[antsvett3]

Hi All,

Strange situation here where I'm seeing traffic traverse a firewall but its not logging. Trying to find a zdebug or equivalent that would tell me the rule number being hit. Any assitance would be greatly appreciated.

Thanks,

Anthony

[Vincent_Bacher]

As fw ctl zdebug + drop Shows all dropped connections I would say same with accept but I am not sure and id might produce heavy load even in combination with grep. Kernel debug doc should explain.

Or was it 

fw ctl zdebug + monitorall    

or

fw ctl zdebug + monitor

?

[Bob_Zimmerman]

Note that grep is really bad for filtering debug output. For low-volume debugs, you have to wait for the debug to produce a certain amount of data before grep will act on it. For high-volume debugs, the firewall is doing the extra debugging work for all of the caught traffic and throwing 99.9% of it away. Instead, you can filter zdebug just like you do with fw monitor. For example:

fw ctl zdebug -T -F "10.0.1.253,0,192.168.144.120,0,0" -m fw xlate drop

[Vincent_Bacher]

You're right, of course. Thank you for reminding me.

[Bob_Zimmerman]

Poking through debug flags, I thought 'conn' might do it. That one shows it's accepted, but not why. 'monitor' and 'monitorall' just give a view of the packet at the various chain positions ('monitorall' is like an 'fw monitor -p all'). Both 'machine' and 'vm' provide information about the rule evaluation process, but don't seem to provide rule numbers.

Looking at the output of 'machine' and 'vm', I noted mentions of the "Unified Policy". Looking at the output of 'fw ctl debug -m' (which lists modules you can debug and options you can enable on them), one of the modules is UP. It has these options:

error warning info verbose address subject timestamp memory vs coverage module connection policy manager clob memory account rulebase urlf_ssl btime log limit sec_rb prob prob_impl vpn mab match stats probtrc

That looks promising, so I tried it out:

[Expert@DallasticXL-s01-01:0]# fw ctl zdebug -T -F "10.0.3.13,0,0,0,1" -m UP + all
...
...
...
@;206102236.449831;12Feb2026 19:14:25.963349;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {connection} up_manager_fw_handle_first_packet: handling first packet of chain: 0x7fba1e694748;
@;206102236.449832;12Feb2026 19:14:25.963357;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {connection} up_manager_fw_handle_first_packet: [10.0.3.13:7 -> 10.0.1.252:0] ;
@;206102236.449833;12Feb2026 19:14:25.963362;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_handle_init: called for 0x7fba19c45f08;
@;206102236.449834;12Feb2026 19:14:25.963366;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_handle_init: setting 'match_terminating_pos_in_chain' to 0;
@;206102236.449835;12Feb2026 19:14:25.963369;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_handle_init: policy id 1757341665;
...
...
...
@;206102236.450491;12Feb2026 19:14:25.965398;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_rulebase_is_log_required: is_log_globaly_required 1;
@;206102236.450492;12Feb2026 19:14:25.965402;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_sub_policy_get_action_track_info: policy id: 0 rule: 1;
@;206102236.450493;12Feb2026 19:14:25.965405;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_sub_policy_get_rule_track: track: 0, track_code: 0;
@;206102236.450494;12Feb2026 19:14:25.965408;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {rulebase} up_rulebase_get_rule_track: track code 0, rule 0:1;
@;206102236.450495;12Feb2026 19:14:25.965411;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {log} up_manager_is_log_required_more_data: rule not required log: sub policy 0, match state MATCH, rule 1;
@;206102236.450496;12Feb2026 19:14:25.965413;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {log} up_manager_handle_net_log: is_log_required 0;
@;206102236.450497;12Feb2026 19:14:25.965416;[vs_0];[tid_0];[fw4_0];1:[SID: 5958893] {connection} up_manager_fw_handle_first_packet: final action ACCEPT;

Note that this debug is extremely verbose (not on the level of 'ld', but still much more data than I quote above for a single ping). I wouldn't run it without a strict filter on the debug. It seems to contain detailed rule information, though.

[Vincent_Bacher]

Out of curiosity, I tried it out and also sent exactly ONE echo request. Result: 715 (!!) lines. Holy cow!

[the_rock]

Hey Anthony,

Did this ever work? One easy thing to try would be disable/re-enable the rule and install policy, test. Well, disable, install policy, re-enable, push policy again. Just make sure rule is set to log.

[Vincent_Bacher]

„the rule“

Funny 😉

Imagine you have 5k rules and no clue witch could match. 

Then think again about „the rule“. 😉

[the_rock]

Geesh, I dont know why I imagined in my head it was just a single rule lol

[antsvett3]

I found this command.

fw up_execute
Usage: fw up_execute [src=<IP>] [dst=<IP>] ipp=<ip protocol> [sport=<source port>] [dport=<dest port>] [protocol=<protocol>] [application=<application/category>]

Notes: Parameters can be omitted, except the ipp (and dport in case of TCP or UDP).
The order of the parameters does not matter.
Applications can be entered multiple times.

Examples:
1) fw up_execute src=126.200.49.240 dst=10.1.1.1 ipp=1
2) fw up_execute src=10.1.1.1 ipp=6 dport=8080 protocol=HTTP application=Facebook application=Opera

Command Line Interface R80.20 Reference Guide

Just not sure how accurate it is after reading about it in some posts.

fw up_execute command - Check Point CheckMates

[PhoneBoy]

Not sure why you referenced the R80.20 docs when fw up_execute was added in R82.

[antsvett3]

it shows it came about in r80.20. also not running it from r82.

[Vincent_Bacher]

Just tested in R82.10. The first of the given examples does not work as not all mandatory fields {src,dst,dport,in_ifn} given.

[PhoneBoy]

It did exist before R82, but it is far less functional since it didn't support most of the advanced object types, nor did it support NAT.
See the R82 doc: https://sc1.checkpoint.com/documents/R82/WebAdminGuides/EN/CP_R82_CLI_ReferenceGuide/Content/Topics-... 

[Timothy_Hall]

fw up_execute existed well before R82, but sometimes did not return correct results, and it was not an officially supported tool.  Formal support for fw up_execute was added in R82, and in my experience so far, it is now 100% accurate.

[the_rock]

That command is pretty accurate in R82, as Tim indicated. I ran it in the lab few times, as well as with customers, gave pretty accurate results. Did you try it for affected traffic to see what rule(s) it gives?