NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: IP → Firewall → Connections
2. CLI: /ip firewall connection print
3. Filter: /ip firewall connection print where dst-address~"443"
4. Kill one: /ip firewall connection remove [find dst-address~"8.8.8.8"]

Gotchas & notes

• The Connections table only exists when connection tracking is enabled. /ip firewall connection tracking print — if enabled=no (or auto with no stateful rules), the table is empty and connection-state= matching in your rules does nothing.
• On low-end hardware conntrack has a real memory cost; max-entries can be reached on a busy network, causing new connections to fail while existing ones are fine.
• The Reply Dst. Address column shows the NAT translation — the fastest way to confirm a masquerade or dst-nat rule is actually applying.

Steps

1. GUI: Dashboard → FortiView → Sessions, or the *Sessions* dashboard widget.
2. CLI, filtered: diagnose sys session filter dst 8.8.8.8 then diagnose sys session list
3. Counts only: diagnose sys session stat
4. Clear the filtered set: diagnose sys session clear — clears what the filter matches.

Gotchas & notes

• Always set diagnose sys session filter before list. On a production firewall an unfiltered list dumps hundreds of thousands of sessions to your terminal and is effectively a self-inflicted outage of your management session.
• diagnose sys session clear with no filter set clears the entire session table, dropping every connection through the firewall. Run diagnose sys session filter and confirm with diagnose sys session filter (no args prints the current filter) before clearing.
• Reset the filter afterwards with diagnose sys session filter clear; filters persist for the session like ping-options do.
• In the session output, state=may_dirty plus npu info tells you the session is hardware-offloaded — which is why your sniffer and flow debug show nothing for it.
• The policy_id= field in each session is the fastest way to learn which rule permitted a flow.

Steps

1. GUI: Clients and Insights → Traffic show per-client activity, but not a true session table.
2. CLI (gateway): SSH → conntrack -L (if installed) or cat /proc/net/nf_conntrack.
3. Per-client detail: Clients → <client> shows current throughput and recent activity.

Gotchas & notes

• There is no session/state table in the UniFi UI. If you need per-connection visibility you are in the gateway shell reading conntrack, or you are looking at DPI stats instead.
• /proc/net/nf_conntrack is verbose and unformatted; grep for the IP you care about rather than reading it whole.
• Nothing you learn there is actionable from the UI — you cannot kill a single session from the controller, only reconnect or block the client.

Steps

1. NAT translations (the closest thing on a plain router): show ip nat translations — add verbose for timers.
2. With Zone-Based Firewall configured: show policy-firewall sessions and show policy-map type inspect zone-pair sessions.
3. Clear NAT entries: clear ip nat translation *
4. For L2 visibility use show mac address-table instead.

Gotchas & notes

• A stock IOS router is stateless — there is no session table to look at. show ip nat translations only lists flows that are being translated, so untranslated internal traffic is invisible.
• clear ip nat translation * drops every active translation at once; users see connections reset. Prefer clearing a single entry by specifying the protocol/addresses.
• Zone-Based Firewall (ZBFW) adds real stateful inspection and a session table, but it must be explicitly configured with zones and zone-pairs — it is not on by default.

Steps

1. GUI: Monitor → Session Browser — filterable live session list.
2. CLI: show session all filter destination 8.8.8.8
3. Detail on one session: show session id <id> (shows the rule, NAT, and app).
4. Clear: clear session id <id>, or clear session all filter destination 8.8.8.8

Gotchas & notes

• show session id <id> is the richest single-flow view of any vendor here: matched security rule, NAT rule, App-ID, ingress/egress interface, and byte counts in one output.
• clear session all with no filter tears down every session on the firewall. Always attach a filter.
• The Session Browser shows only *active* sessions — a completed connection lives in Monitor → Traffic, not here. Looking in the wrong one wastes time.
• A session in discard state means the firewall decided to drop the flow and is holding the state to avoid re-evaluating it; clearing that session is often needed after you fix the policy.

Steps

1. GUI: Diagnostics → States — filter by address or port; each row has a kill button.
2. Summary by host: Diagnostics → States Summary.
3. Live top-style view: Diagnostics → pfTop.
4. CLI: pfctl -ss (show states), pfctl -si (info/counters), pfctl -k <host> (kill states for a host).

Gotchas & notes

• Killing states is often the missing step after a rule change. pf keeps existing states regardless of new rules, so a new block rule appears not to work until the state is cleared here.
• pfctl -k 192.168.1.50 kills all states for one host — a targeted alternative to the nuclear *Reset States* button under Diagnostics → States → Reset States.
• The state table has a configurable maximum (System → Advanced → Firewall & NAT → Firewall Maximum States). Hitting it produces intermittent connection failures with a healthy-looking CPU; check pfctl -si for state limit counters.
• The state entries show both the original and translated addresses, making this the place to verify outbound NAT behaviour.

Steps

1. Open the live connection cache: Dashboard → Connections (on Gen7 this may also surface under an Investigate/monitoring grouping, but the underlying page is the same connection-cache view carried over from Gen6).
2. Use the filter fields to narrow by source, destination, service, or interface/zone — each row shows the session's original source/destination and, for NAT'd flows, the translated address/port.
3. Select a specific connection and use Flush to terminate that single stuck session, or Flush All to clear the entire cache (heavy-handed — it drops every active session through the box).
4. Cross-reference with Log → Event Logs if you need to see why a particular flow was allowed or dropped, since the connection view itself shows state, not the policy decision.

Changed across versions

• SonicOS 6.5 (Gen6)The page is simply the 'Connections' tab under the top-level Dashboard button; Gen7's broader navigation reorganization moved a lot of monitoring pages around, but this view's content and filtering behavior carried forward largely unchanged.

Gotchas & notes

• This is a GUI-only feature. SonicOS's CLI diagnostic commands (interface counters, ARP table, routing table, ping/traceroute) do not include an equivalent dump of the live session/NAT cache — for this task the CLI is a genuine dead end, consistent with SonicWall reserving the CLI for bootstrap setup and basic diagnostics rather than full GUI parity.
• The number of tracked connections is capped by the appliance's model/license tier (shown on the Dashboard). On smaller TZ-series boxes, hitting that ceiling under load is a real, hardware-sizing failure mode — not just a display truncation — and it presents as random new connections failing to establish.
• 'Flush All' clears every session on the firewall, not just the one you're chasing — on a busy box this is disruptive enough that most admins filter down to the specific stuck flow and flush just that row instead.

Steps

1. There is no live session/connection table (5-tuple + state + translation) exposed anywhere in Insight for routers or Orbi Pro, and no CLI exists on those devices to query one either.
2. The closest available visibility is Insight app/portal → Locations → device (or network-wide) → Traffic / Insights, which shows aggregated per-client bandwidth and (with an Insight Premium subscription and DPI-capable hardware) top applications/categories — this is analytics, not a connection table, and it has no per-flow source/destination/port detail or idle timers.
3. To 'clear a stuck connection' the only real lever is indirect: Insight app → Clients → select device → Block/Reconnect, or reboot the router/AP from Insight. Neither operation targets a specific flow — they drop the client's whole session or the device's whole NAT state at once.
4. M4200/M4300 switches, being L2/L3, don't maintain a NAT/session table either — their CLI can show MAC address tables, ARP, and routing tables, but nothing analogous to a firewall state table, because they aren't performing stateful inspection.

Gotchas & notes

• This is the sharpest contrast with the stateful-firewall vendors in this comparison (FortiGate diagnose sys session list, pfSense Diagnostics → States, PAN-OS session browser) — Insight-managed routers genuinely have nothing equivalent, cloud portal or otherwise.
• If you're troubleshooting 'is this port forward actually being hit,' you cannot watch it happen — there's no hit counter, no session log, no packet counter per rule. You're reduced to testing from outside and watching the destination host's own logs.
• The Insight Premium traffic/application visibility feature requires DPI-capable hardware and an active Premium subscription — on Insight Essentials (free tier) or older/non-DPI hardware you don't even get the aggregated view, let alone anything resembling a session table.
• Don't confuse this with the Smart Switch or M4200/M4300 CLI having some hidden session-table command — those platforms' Lite CLI and IOS-style CLI are for switching/L2-L3 config and monitoring, not firewall state, because NAT/stateful filtering isn't something those boxes do.