Monitor Firewalls via SNMP

The firewall is the one box every packet crosses, so when it slows down everything behind it slows down with it. SNMP firewall monitoring gives you a steady read on that chokepoint — interface throughput, link state, session load, CPU and memory — without shelling into the appliance every time something feels off. This page walks through what firewalls expose over SNMP, the OIDs worth polling, how to enable it on the two platforms people ask about most, and why the most important place to watch a firewall from is outside the network it guards.

SNMP support on Firewalls

Practically every firewall platform speaks SNMP, because SNMP is how they've always fit into a wider NMS. The agent is built in; you enable it rather than install it. Most support SNMPv1 and SNMPv2c with a community string, and modern appliances add SNMPv3 for authenticated, encrypted polling — which matters more on a firewall than on almost anything else, since the device sits at the edge where the untrusted side can see it.

What they expose splits neatly in two. The standard trees are common to all of them: the IF-MIB (RFC 2863) for every interface — WAN, LAN, VLANs, tunnels — and the MIB-II system group (RFC 1213) for identity and uptime. Then each vendor layers an enterprise MIB on top for the things only a firewall has: active session or connection counts, VPN tunnel state, throughput per policy, HA cluster role. For pfSense SNMP, the agent is standards-based and leans heavily on the IF-MIB plus host resource and UCD-style trees, since pfSense is built on FreeBSD. For FortiGate SNMP, FortiOS exposes the standard interface counters alongside Fortinet's own enterprise MIB for session tables and system health. The pattern holds across brands: interfaces and system basics are portable, everything firewall-specific is vendor MIB territory — and you should load that vendor MIB rather than guess at object numbers.

What you can monitor on Firewalls

Start with the interface and system metrics that every firewall reports the same way, then reach into the vendor MIB for the session-level detail that makes a firewall a firewall.

The interface rows do most of the heavy lifting. Bandwidth on a WAN uplink comes from the delta of ifHCInOctets/ifHCOutOctets over time — use the 64-bit ifXTable counters, because a gigabit link overruns the old 32-bit ones in seconds — and the mechanics live on the interface traffic sensor page. Whether a link is actually up is ifOperStatus, covered under interface info; a WAN that flips to down is often your first sign of an ISP problem. Rising input errors or discards, which the interface errors page unpacks, tend to show up before users start complaining.

Session count is the metric unique to firewalls, and it's the one people most want alerted. A state table filling toward its limit is a slow-motion outage: once it's full, new connections are refused and the firewall looks "down" while pinging fine. That number lives in each vendor's enterprise MIB — walk the vendor MIB on your specific model to find the exact object, and never assume a session-count OID from one brand applies to another. Appliance CPU and memory are similar: exposed, useful for spotting a device running hot under a traffic surge, but reported through vendor objects rather than a single universal OID.

Enabling SNMP — steps

The concept is identical everywhere — turn on the service, set a community or v3 user, restrict who may query — even though the menus differ. Two of the most common:

1. pfSense: open Services → SNMP, tick Enable, set a read-only Community String, and bind the service to your management interface only — not WAN.
2. pfSense (optional modules): enable the interface and host-resource modules so the IF-MIB and system counters are populated, then save and let the service restart.
3. FortiGate (GUI): under System → SNMP, enable an SNMP v2c community (or an SNMPv3 user), and add the IP of your poller as a permitted host.
4. FortiGate (per-interface): on each interface's administrative-access settings, allow SNMP so the appliance will answer on that interface.
5. Verify from your poller with any Net-SNMP client:

   snmpwalk -v2c -c public 10.0.0.1 1.3.6.1.2.1.2.2.1
   

A few rules keep this safe rather than sorry:

• Never bind the SNMP service to the WAN/untrusted interface. Answer only on the management side, and lock it to your poller's IP.
• Change the default UDP 161 where the appliance is broadly reachable — see the custom port guide.
• Publish only the OIDs you poll with an OID allowlist so a scanner can't enumerate the device.
• Prefer SNMPv3 on any edge-facing firewall; a v2c community crosses the wire in clear text.

If a walk hangs or returns nothing, the troubleshooting guide works through the usual causes — service bound to the wrong interface, a host-allow list that omits your poller, or a mismatched community.

Monitoring it externally

There's an irony built into watching a firewall: the tool that alerts you usually lives behind the firewall it's watching. When the appliance saturates its session table or the WAN drops, that internal monitor is cut off from the outside world at exactly the moment you need the page to reach your phone. It shares fate with the device.

Polling from outside breaks that dependency. An independent checker on the public side keeps reading sysUpTime and the interface counters, so a firewall that has stopped forwarding — or stopped answering entirely — becomes the alert instead of a silence nobody notices. That's the case for double durability: a watcher beyond your perimeter still sees the box when the box can't reach out.

ostr.io Monitoring is built for exactly this. It polls your firewall's SNMP from outside your network as a zero-setup SaaS and sends real-time email and SMS alerts when an interface goes down, throughput flatlines, or the device stops responding — no internal collector to be stranded behind the very firewall that failed.