NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. RouterOS has no flow tracer. Instrument the path instead: add log=yes log-prefix="R1" to the candidate rules and watch /log print follow.
2. Check whether the connection exists at all: /ip firewall connection print where dst-address~"8.8.8.8"
3. Verify routing separately: /ip route check 8.8.8.8
4. Count matches per rule: /ip firewall filter print stats — the byte/packet counters show which rule is actually being hit.

Gotchas & notes

• /ip firewall filter print stats is the practical substitute for a flow trace: reset counters with /ip firewall filter reset-counters-all, reproduce the traffic, then look for which rule incremented.
• /ip route check <ip> is an underused command that returns the chosen gateway and interface — it separates a routing problem from a firewall problem in one step.
• Remember RouterOS evaluates chains in order with first-match-wins and that NAT (dstnat) happens *before* the forward filter chain, so filter rules must match the post-NAT destination address.

Steps

1. Set a filter so you only trace the flow you care about: diagnose debug flow filter addr 8.8.8.8 and optionally diagnose debug flow filter port 443
2. diagnose debug flow show function-name enable
3. diagnose debug enable
4. diagnose debug flow trace start 100 (trace the next 100 packets)
5. Reproduce the traffic, read the output, then always finish with diagnose debug disable and diagnose debug reset.

Gotchas & notes

• diagnose debug flow is the best troubleshooting tool on the platform — it prints the matched policy ID, the route chosen, and the exact reason for a drop (Denied by forward policy check, reverse path check fail, no session matched).
• Forgetting diagnose debug disable leaves debug output streaming to your session and burning CPU. On a busy firewall an un-filtered flow debug is genuinely disruptive. Set the filter *first*, every time.
• Offloaded sessions skip the CPU path, so an established session may produce no trace output. Clear the session first (diagnose sys session filter + diagnose sys session clear) so you trace the initial packet.
• reverse path check fail in the output means asymmetric routing / RPF, not a policy problem — a distinct fix from adding a rule.
• Companion command for 'which policy would match': diagnose firewall iprope lookup <src> <sport> <dst> <dport> <proto> <interface>.

Steps

1. There is no flow-trace or policy-test tool in the UniFi Network UI.
2. Nearest options: enable Log on the suspect firewall rule and read it via remote syslog, or SSH to the gateway and use tcpdump on the inbound and outbound interfaces to see where the packet stops.
3. On gateways you can also inspect the underlying tables directly: iptables -L -v -n (older UDM firmware) or nft list ruleset (newer).

Changed across versions

• 8.x and earlierRule evaluation follows the directional model — *Internet In*, *LAN In*, *LAN Local* — in that conceptual order. Reasoning about "which rule fired" means picking the right ruleset tab first.
• 9.0+Zone-Based Firewall changes evaluation to zone-pair policies (source zone → destination zone). A rule-order mental model carried over from 8.x will point you at the wrong ruleset entirely — confirm which model is active (Settings → Security) before tracing a drop.

Gotchas & notes

• Comparing a tcpdump on the ingress interface with one on the egress interface is the standard workaround: seen in, not seen out, means the gateway dropped it.
• The underlying nftables/iptables ruleset is generated by the controller. Read it for diagnosis, but never edit it — the next provision overwrites your change.

Steps

1. For ACLs, read the hit counters: show access-lists ACL_NAME shows matches per line.
2. Confirm the routing decision: show ip route 8.8.8.8 and show ip cef 8.8.8.8 (which gives the real forwarding path).
3. With Zone-Based Firewall: show policy-firewall sessions and show policy-map type inspect zone-pair.
4. Packet-level proof: use Embedded Packet Capture with a match for the flow (see the packet capture task).

Gotchas & notes

• show ip cef <destination> beats show ip route when they disagree — CEF is what actually forwards the packet, and a route/CEF mismatch is a real failure mode.
• ACL counters only increment for process- and CEF-punted matches you have not disabled; on some platforms hardware-accelerated ACLs do not update the software counters, making a working rule look unused.
• IOS has no equivalent to FortiGate's flow debug. debug ip packet exists but is dangerous on production — it can wedge a busy router. If you must, restrict it with an ACL: debug ip packet 101 detail.

Steps

1. GUI policy test (no traffic needed): Device → Troubleshooting → Security Policy Match — fill in source, destination, ports, application, and it names the matching rule.
2. CLI equivalent: test security-policy-match source 10.1.1.5 destination 8.8.8.8 destination-port 443 protocol 6 application ssl
3. Also available: test nat-policy-match ... and test routing fib-lookup virtual-router default ip 8.8.8.8
4. For real traffic, read Monitor → Traffic — each log line shows the rule name and the session end reason.

Gotchas & notes

• Device → Troubleshooting is the best-kept secret in PAN-OS: it answers 'which rule will match this?' without generating any traffic. Nothing else in this list has a true offline policy simulator.
• test security-policy-match evaluates the running config, so a change you have not committed will not be reflected. Commit first or you are testing the old ruleset.
• The *session end reason* column in the Traffic log (policy-deny, aged-out, tcp-rst-from-client, threat) usually diagnoses the problem on its own.
• App-ID means a rule can match on port and still deny once the application is identified. If a session appears then dies, check whether the rule needs the specific App-ID rather than application-default.
• show counter global filter severity drop explains dataplane discards that never reach policy at all.

Steps

1. Status → System Logs → Firewall and filter on the source or destination IP — blocked packets are logged by default, with the matching rule shown.
2. Check live state: Diagnostics → States, filter by IP, to see whether a session was established.
3. Confirm the route: Diagnostics → Routes, and Diagnostics → Tables for alias contents.
4. Ruleset as pf sees it: Diagnostics → Command Prompt → pfctl -sr -vv (shows per-rule evaluation and match counts).

Gotchas & notes

• pfctl -sr -vv prints every rule with its evaluation/match/packet counters — the closest thing pfSense has to a flow trace, and it reveals rules that never match.
• Because pfSense logs the default-deny, the Firewall log tab usually answers the question in seconds. Check that *Log packets matched from the default block rules* is still enabled in Status → System Logs → Settings.
• pfSense filters on the inbound direction of each interface by default. A rule on the wrong interface tab is the most common reason traffic is blocked despite an apparently correct rule.
• Existing states survive rule changes: after tightening a rule, kill the relevant state in Diagnostics → States or the old session keeps flowing.

Steps

1. SonicOS has no single purpose-built 'explain this flow' debug command (nothing like FortiGate's diagnose debug flow or a PAN-OS policy-match test) — the answer here is assembled from Packet Monitor plus the logs, not one query.
2. Configure Investigate > Tools & Monitors > Packet Monitor with a filter matching the exact source/destination/port/protocol in question, enable Notification, and start the capture.
3. Generate the traffic. In the captured-packet grid, dropped packets are tagged with the reason/rule that caused the drop — this inline drop-reason tagging is the closest thing SonicOS has to a real flow tracer.
4. Cross-check against Log > System Logs (for a completed connection) or Investigate > Connections (for one still open), filtered by the same source/destination — a logged permit/deny event names the matching Access Rule.
5. If the traffic doesn't even reach the point expected, separately check Network > Routing > Route Policies for the route match — SonicOS won't tell you in one screen whether a drop was a policy mismatch or a routing problem, so route table, capture, and log have to be correlated by hand.

Gotchas & notes

• This is the weakest point in SonicOS versus purpose-built flow tracers on other platforms: there's no single command that answers 'why was this allowed/denied' — you're combining Packet Monitor's per-packet drop reason, the traffic log, and (sometimes) the route table yourself.
• Packet Monitor's drop-reason tagging only appears if 'Notification' was enabled *before* you captured — a plain capture without it just shows the packet disappearing, not why.
• If the matching Access Rule didn't have Logging enabled, the traffic log says nothing about the event even though Packet Monitor may still show the drop — the two tools cover different gaps, which is why serious flow troubleshooting on SonicOS usually means running both at once rather than trusting either alone.

Steps

1. There is no purpose-built flow tracer or 'why was this session allowed/blocked' tool anywhere on this platform — not in Insight, not in the local switch GUI, not in any of the three CLI tiers.
2. Closest workaround on an Insight-managed router: check Insight's Security/Firewall or VPN log for a matching event by timestamp and IP. This confirms something happened; it doesn't tell you which rule evaluated it or why, in what order.
3. Closest workaround on a switch with ACLs (M4200/M4300 only, since Smart Switches and the Lite CLI don't support this depth of ACL): configure the relevant ACL entry with a log keyword ahead of time and check hit counters via show access-lists <name> — this only works for traffic you anticipated and pre-instrumented.
4. There is no 'test this 5-tuple against my ruleset' command anywhere — you read the rule/ACL order yourself and reason about it manually.

Gotchas & notes

• If you're used to PAN-OS's Test Policy Match or FortiGate's session/flow debug tooling, stop looking — it genuinely doesn't exist on any NETGEAR Insight-managed device. The router-class firewall here is a short, simple rule list with no diagnostic layer built on top of it.
• ACL hit-counter logging on the M4300 is the closest real feature, but it's after-the-fact and per-rule — you can't ask 'what would happen to this packet,' only look at what already got logged, and only if you thought to enable logging on that ACL beforehand.
• Because the firewall config on Insight-managed routers lives in the cloud, even 'read the ruleset yourself' means reading Insight's rule-list UI — there's no local show running-config-equivalent single source of truth for firewall rules the way there is on the M4300 CLI.