topic Re: Fw monitor troubleshooting in Firewall and Security Management

Fw monitor troubleshooting

Ven — Thu, 05 Nov 2020 08:50:03 GMT

Hello,

I have a question about Fw monitor Inspection Points iIoO. What does if i don`t see these inspection points in the fw monitor output and what could be the cause for each and also how to troubleshoot ?

For example : If i don`t see ' i ' ----I am thinking that the traffic/connection is not even reaching the firewall and I would look at the forwarding device if it is sending the tarffic to fw or not ?

If i don`t see 'I' --

If i don`t see 'o' ---

If i don`t see 'O' ---

Any help appreciated

Re: Fw monitor troubleshooting

PhoneBoy — Sun, 08 Nov 2020 03:29:13 GMT

You're correct on i.
If something doesn't get to I, it's most likely got dropped by a policy/access rule
If something doesn't get to o, the packet probably didn't get routed properly or it's being handled directly by the gateway.
If something doesn't get to O...well, it depends on the precise situation.

Re: Fw monitor troubleshooting

HeikoAnkenbrand — Sun, 08 Nov 2020 11:33:03 GMT

Hi @Ven

I agree with @PhoneBoy. Here is a small note.
In different versions the "fw monitor inspection points" are displayed differently.

For example, you cannot see "i" or "O" when it is VPN traffic on certain GAIA versions.

More read here:
- R80.x - Security Gateway Architecture (Logical Packet Flow)
- R80.x - Performance Tuning and Debug Tips - fw monitor
- R80.x - cheat sheet - fw monitor

Re: Fw monitor troubleshooting

Ven — Mon, 09 Nov 2020 18:25:40 GMT

Thanks @PhoneBoy for your help.

Re: Fw monitor troubleshooting

Ven — Mon, 09 Nov 2020 18:26:55 GMT

Thanks @HeikoAnkenbrand for your notes

Re: Fw monitor troubleshooting

Timothy_Hall — Sun, 07 Feb 2021 19:21:15 GMT

Just to add on to Daemon's post: if traffic disappears at I it may have been dropped as he says (fw ctl zdebug + drop to check this), but it is also possible that your filter was matching against only the pre-NAT destination IP address. If it is the destination IP address that is subject to NAT, the actual replacement of the destination IP address in the packet happens between i and I. So in this case the packet "disappears" in your capture and never reaches I (as far as you can see), but the packet actually just stopped matching your pre-NAT destination IP address filtering condition and continued onwards through I.

By the same token if the traffic seems to disappear after o, it is possible that the packet was dropped (though much less likely than between i and I) for some reason. What is far more probable is that you were matching against the pre-NAT source IP address, which will be transformed to the post-NAT source IP address between o and O, and the packet will once again seem to "disappear" in your capture, when in reality the packet was not dropped and continued through O.