Constant monitoring with 'zdebug drop'

[Matlu]

Hi, Mates.

A query, the command

#fw ctl zdebug drop | grep 'Destination IP'

can be left 'running' in the background in order to 'monitor' a particular IP and know if during the day, the command 'registers' something relevant?

We do this in order to capture traffic at the exact moment, because unfortunately when we apply the command in real time everything works fine, but just when we stop testing, the connection between 1 source and 1 destination begins to fail and we have no records of those precise moments.

Is this possible?

Greetings.

[the_rock]

Here is what I always do. Say src is 1.1.1.1, dst 2.2.2.2 and port 4434

fw ctl zdebug + drop | grep 1.1.1.1 | grep 2.2.2.2 | grep "4434" > /var/log/zdebug.txt

Andy

[Bob_Zimmerman]

If you intend to debug NAT, you probably need to change one of the filters. The filter expressions need to match the packet as the firewall receives it.

If you don't intend to debug NAT, you should remove the xlate debug flag. Also, it sounds like you may need a + in there after the 'fw': '-m fw + drop'.

The information I see in the debug seems to say VS 2 is failing to associate traffic with a zone. Are you using zone-based rules? If so, check the interfaces on VS 2 and make sure all of the interfaces have an associated zone.

[Matlu]

Hello,

I don't want to debug NAT, because in the instance where I am applying the command you recommended, I am not doing NAT.
I just need that the zdebug, can be as granular and capture traffic with the source, destination and destination port data.

And this Source, Destination, Destination Port traffic is in VS ID 6 not VS ID 2.

I am not working with zones.

I apply the command you recommended, removing only the “xlate” parameter, correct?

Greetings.

[PhoneBoy]

Something to be aware of here: you can only run one "debug" at a time.
fw monitor can also impact debugs. 
Also, debugs have a performance impact, so if you're going to leave one running for a long period of time, it should be very narrowly focused.
The "not zdebug" method @Bob_Zimmerman suggests is probably your best bet, but it might impact your ability to troubleshoot other issues at the same time.