NetCrosswalk: Cross-Vendor Network Task Translator

Steps

1. GUI: Log in the left menu (WinBox).
2. CLI: /log print — or follow live with /log print follow
3. Filter: /log print where topics~"dhcp"
4. Log a firewall rule by setting action=log on it, or log=yes log-prefix=BLOCKED on the existing rule.

Gotchas & notes

• By default logging goes to memory only and the buffer is small (a few hundred lines), so it wraps within minutes on a busy box and is lost on reboot. Configure /system logging action to add disk or a remote syslog before you need it.
• RouterOS has no per-connection traffic log at all by default — firewall rules are silent unless you add log=yes. Coming from FortiGate or PAN-OS, expect this absence.
• Use log-prefix= on each rule you instrument; without it you cannot tell which of five similar rules fired.
• Turning on log=yes for a high-volume rule will flood the log and can spike CPU. Instrument narrowly and turn it off afterwards.

Steps

1. GUI: Log & Report → Forward Traffic for per-session traffic, Log & Report → System Events for the event log.
2. Enable traffic logging per policy: edit the firewall policy → *Logging Options* → Log Allowed Traffic: All Sessions.
3. CLI live view: execute log filter category 0 then execute log display
4. Realtime debug (not a log): diagnose debug flow — see the traffic-flow trace task.

Gotchas & notes

• Entry-level FortiGates have no internal disk, so local logging is memory-only and tiny; the *Forward Traffic* view will look almost empty. Real retention needs FortiAnalyzer, FortiCloud, or a syslog server (Log & Report → Log Settings).
• A policy logs nothing unless *Log Allowed Traffic* is enabled on that policy — a common false conclusion is 'no traffic is matching' when it is simply not being logged.
• Denied traffic is only logged if you enable it globally: config log setting → set local-in-deny-unicast enable / implicit-deny logging, depending on version.
• The GUI log view respects a time filter that defaults to a narrow window; widen it before concluding a session is missing.

Steps

1. UniFi Network → Insights (or *Events*, depending on version) for adoption, roaming, and connectivity events.
2. Per-client history: Clients → <client> → history/timeline.
3. Send elsewhere: Settings → System → Advanced → Remote Logging (syslog).
4. Firewall logging: enable *Log* on the individual firewall rule, then view via syslog.

Gotchas & notes

• UniFi's event list is oriented around Wi-Fi and device lifecycle events, not packets. There is no browsable per-session traffic log in the UI comparable to FortiGate's Forward Traffic.
• Firewall rule logs are not shown in the UniFi UI in a useful way — you need to configure remote syslog to actually read them.
• Retention is short and tied to the controller's storage. A Cloud Key with a full disk quietly stops retaining history.
• Events are controller-side: if the controller was offline, the outage window you most want to investigate has no data.

Steps

1. show logging — the in-memory buffer plus current logging config.
2. Make sure buffering is on and big enough: logging buffered 65536 informational
3. Timestamps that are actually usable: service timestamps log datetime msec localtime show-timezone
4. Remote: logging host 10.0.0.5

Gotchas & notes

• If you are on the console/SSH and messages interrupt your typing, logging synchronous under line con 0 / line vty 0 4 fixes it — a quality-of-life fix everyone should apply.
• Default service timestamps shows uptime, not wall-clock time, making correlation with other devices impossible. Set datetime msec early.
• ACL hits are only logged if you add the log keyword to the ACE, and ACL logging is process-switched — it can hammer the CPU on a busy device. Use sparingly and remove afterwards.
• show logging output is cleared by a reload; there is no persistent local log without an external syslog server or the archive feature.

Steps

1. GUI: Monitor → Logs → Traffic for sessions, Threat for IPS/AV, System for the event log, Configuration for who changed what.
2. Filter with the query bar, e.g. ( addr.src in 10.1.1.5 ) and ( port.dst eq 443 ).
3. CLI: show log traffic direction equal backward or less mp-log ms.log for management-plane logs.
4. Enable per rule: Security policy → *Actions* → Log at Session End.

Gotchas & notes

• Log at Session Start vs Session End matters: session-end is the default and correct choice, but a long-lived session will not appear until it closes — so an active connection can look absent.
• The Configuration log is the best change-audit trail of any vendor here; it records the admin, the exact XPath, and before/after values. Use it before blaming the network.
• Interzone-deny drops are logged only if you explicitly enable logging on the default interzone rule (Policies → Security → the greyed-out default rules can be overridden).
• Local log storage is quota-based per log type (Device → Setup → Management → Logging and Reporting Settings). A small traffic-log quota silently ages out the data you need.

Steps

1. GUI: Status → System Logs → System for events, and Status → System Logs → Firewall for packet-filter hits.
2. The Firewall tab has a *Normal View* with a red/green icon per entry and a handy 'easy rule' add link.
3. CLI: clog /var/log/filter.log (CE 2.7 and earlier) or tail -f /var/log/filter.log.
4. Adjust retention/size: Status → System Logs → Settings.

Gotchas & notes

• pfSense logs blocked packets by default, which is the opposite of MikroTik and very handy — the Firewall log is usually the fastest answer to 'why is this not working'.
• Logs are circular and small by default (a few hundred KB per log). Increase the size in Settings or ship to syslog if you need history.
• Click the rule icon next to a firewall log entry to jump to the exact rule that matched — the single most underused feature in the pfSense UI.
• The default-deny drops appear with a rule description like *Default deny rule IPv4*; seeing those means no rule matched, not that a rule blocked it deliberately.

Steps

1. Event/system log: Log > System Logs (called "Log > View" pre-7.0) — a chronological list of system, admin, auth, and VPN events, filterable by category and priority.
2. Live per-connection view: Investigate > Connections shows currently active sessions with source/destination, interface, and the NAT/rule that matched.
3. To ensure a specific Access Rule actually produces traffic-log entries, open Policy > Rules and Policies > Access Rules, edit the rule, and confirm Logging is enabled — logging is a per-rule checkbox, so a rule left unlogged generates no traffic-log history at all.
4. For anything beyond the box's own short local retention, configure Log > Settings > Syslog to forward events to a syslog server, or point it at SonicWall's Capture Security Center/Analyzer/GMS if licensed — local flash/RAM log storage on the appliance is small and rolls over quickly, especially on smaller TZ models.

Gotchas & notes

• 'Logs' on SonicOS covers two genuinely different things: the event log (system/admin/VPN activity) and the per-session traffic/connection log — and unlike some vendors, useful long-term traffic logging really requires a syslog server or SonicWall's own analyzer product; local retention is short.
• Whether you can answer 'was this dropped and by what rule' after the fact depends entirely on whether that specific Access Rule had Logging turned on *before* the traffic occurred — there's no retroactive reconstruction if it wasn't.
• There is no practical CLI log viewer for this — you're in the GUI, or reading what got forwarded to syslog, not running a CLI command.

Steps

1. Cloud/GUI (all device types): Insight portal/app > device > Logs (sometimes Support > Logs or Topology > device > Events) shows the system/event log — reboots, config pushes, uplink flaps, client connect/disconnect. This is the primary and only log view for routers and Orbi Pro APs.
2. Local GUI (switches): Maintenance > System Logs (or Monitoring > Logs) on the switch's own local HTTPS page shows the same buffered log even without Insight.
3. CLI (M4200/M4300): show logging buffered for the in-memory log; logging host <ip-address> to point at a remote syslog server for persistent history, since the local buffer wraps quickly.
4. CLI (Smart Switch Lite CLI): a basic show log-style command surfaces recent system events, with a noticeably shorter buffer than the M4300 line.
5. Per-connection traffic logs: Insight's router firewall logs discrete security/VPN events under the Security or VPN log views, but there is no searchable per-5-tuple 'allowed/denied, matched rule X' traffic log anywhere on this platform.

Gotchas & notes

• None of the three tiers retain meaningful history locally — the on-device buffer is small and rotates fast. If you need real history, logging host on the M4300 is your only real option; Smart Switches and Insight-managed routers/APs mostly don't expose remote syslog configuration at all.
• Insight's own log view is cloud-dependent — if the device's tunnel is down, you only see whatever synced before it dropped, and on many router models there's no local GUI fallback to check once the device is Insight-claimed.
• Don't go looking for a FortiGate/PAN-OS-style session table or per-rule traffic log — it does not exist on any tier here. Firewall rule counters, where present at all, are pass/fail counts, not a searchable log.