devices

SNMP Monitoring for Firewalls: Throughput, Sessions & Health

Monitor firewalls over SNMP — interface throughput and health via standard MIBs, plus session/connection counts and HA state via vendor MIBs (Palo Alto, Fortinet, pfSense).

By the SNMP Monitoring team · Reviewed July 2026

A firewall is a choke point — every packet between zones passes through it — so its health gates the whole network. When a firewall's session table fills or its CPU saturates, everything behind it suffers. SNMP is a solid way to watch that health: interface throughput and system resources come from standard MIBs, while the metrics that matter most on a firewall — session counts, HA state, policy stats — are vendor-specific. This guide covers the standard baseline plus where Fortinet, Palo Alto, and pfSense keep their proprietary data, with the usual rule: name the MIB, link the vendor, don't invent leaf OIDs.

Parent: devices. Related: interface sensor, alerting.

Enabling SNMP

Enabling SNMP varies by vendor — a web UI on some, a CLI on others — but the security principles are constant, and they matter more on a firewall than almost anywhere:

  • Set a random read-only community, or better, an SNMPv3 user — never public.
  • Restrict polling to your manager's source IP with the device's SNMP host allowlist.
  • Add a firewall rule (the device is its own firewall) permitting UDP 161 only from the manager.
  • Keep it read-only — a security device should never accept SNMP writes.

Because a firewall is a high-value target, treat its SNMP exposure with extra care: v3 where supported, tight source restriction, and no cleartext community on any untrusted path. Broader hardening is on security hardening.

Standard metrics

The portable baseline works on every firewall. IF-MIB gives you per-interface throughput and status — the bytes in/out and up/down state on each zone interface, which is the core of firewall traffic monitoring. Many firewalls also expose HOST-RESOURCES-MIB for CPU and memory, letting you watch the device's processing load. These standard metrics alone tell you a lot: an interface saturating, a CPU pegged, a link down. The interface counters are detailed on the interface sensor page, and per-interface throughput on network monitoring.

Vendor metrics: sessions, HA, policy

The firewall-specific metrics — the ones a generic server doesn't have — live in vendor MIBs under each vendor's enterprise branch:

VendorMIB / enterpriseVendor metrics
FortinetFORTINET-FORTIGATE-MIB (1.3.6.1.4.1.12356)Sessions, HA, CPU, policy
Palo AltoEnterprise 1.3.6.1.4.1.25461Sessions, HA, throughput
pfSenseBSD / UCD-based MIBsSystem resources, states

The single most valuable firewall-specific metric is usually the active session (connection) count — how full the session table is. A firewall that hits its session limit drops new connections even with CPU to spare, so watching session-table utilization catches a failure mode the standard MIBs miss entirely. HA state is the other one: knowing which unit is active/passive and detecting a failover is critical on a redundant pair. Both are vendor-specific — look them up in the FORTINET-FORTIGATE-MIB, Palo Alto's MIB, or pfSense's BSD/UCD objects for your platform. Verify the exact leaf against the vendor MIB; don't assume a session-count OID.

The reason session monitoring deserves this emphasis is that it catches a failure the obvious metrics miss. Operators instinctively watch CPU and throughput, but a firewall can sit at moderate CPU and comfortable bandwidth while its session table quietly fills — from a connection-heavy application, a scan, or a slow leak of unclosed connections. When that table hits the platform's maximum, the firewall starts refusing new connections, and users experience an outage that the CPU and interface graphs don't explain. Tracking session-table utilization as a percentage of the device's rated capacity turns that invisible ceiling into a metric you can alert on before it bites. Pair it with HA-state monitoring and you cover the two firewall-specific failure modes — exhaustion and failover — that generic server monitoring simply has no concept of.

Reading with snmpwalk

Confirm SNMP and identify the firewall:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 system
SNMPv2-MIB::sysDescr.0 = STRING: FortiGate-100F ...
SNMPv2-MIB::sysName.0 = STRING: fw-edge01

The sysDescr names the platform, which tells you which vendor MIB applies. Then walk interfaces for throughput:

snmpwalk -v2c -c S3cr3tR0str1ng 10.0.0.20 ifName
IF-MIB::ifName.1 = STRING: port1
IF-MIB::ifName.2 = STRING: port2

Map the port indices to your zones, then read ifHCInOctets/ifHCOutOctets for throughput. With the vendor MIB loaded, walk the vendor subtree by name to find the session-count and HA-state objects your platform exposes.

What to alert on

A firewall's alert set is distinctive because of the session dimension:

  1. Session-table saturation — alert well before the session count hits the device limit; this is the firewall-specific failure the standard MIBs can't see.
  2. Interface throughput — near line-rate on a zone interface signals a capacity or attack condition.
  3. HA failover — alert immediately on any change in HA active/passive state.
  4. CPU / memory — sustained high CPU on a firewall degrades everything behind it.

Set warning and critical thresholds on each, and treat session-table and HA alerts as high priority — they're the ones unique to firewalls. Alerting patterns are on alerting.

Frequently asked questions

How do I monitor a firewall with SNMP?

Enable SNMP on the firewall (vendor UI or CLI) with a random read-only community or SNMPv3 user, restricted to your manager's IP. Poll standard MIBs for interface throughput (IF-MIB) and CPU/memory (HOST-RESOURCES where present), and the vendor MIB for firewall-specific metrics like session counts and HA state. Alert on session-table saturation, throughput, HA failover, and CPU.

What OID is the firewall session count?

It's vendor-specific — there's no standard OID for active sessions. Fortinet exposes it in the FORTINET-FORTIGATE-MIB (1.3.6.1.4.1.12356), Palo Alto under 1.3.6.1.4.1.25461, and pfSense through BSD/UCD-based objects. Load your vendor's MIB and look up the session-count leaf for your platform rather than assuming an OID; the exact object varies by vendor and model.

Which MIB do Fortinet and Palo Alto use for SNMP?

Fortinet uses the FORTINET-FORTIGATE-MIB under enterprise 1.3.6.1.4.1.12356, and Palo Alto uses its enterprise tree at 1.3.6.1.4.1.25461. Both expose vendor-specific data like sessions, HA state, and throughput there, while interfaces and basic resources come from the standard IF-MIB and HOST-RESOURCES-MIB. Check each vendor's MIB documentation for the specific leaves.

Can SNMP show firewall HA failover?

Yes, through the vendor MIB. HA (high-availability) state — which unit is active or passive — is exposed as vendor-specific objects, so you can poll it and alert on a change that indicates a failover. It's not in the standard MIBs, so you'll find it in the FORTINET-FORTIGATE-MIB, Palo Alto's MIB, or your platform's equivalent; verify the exact OID against the vendor documentation.

Key takeaways

  • A firewall is a choke point — its health gates the whole network, so monitor it closely.
  • Standard MIBs cover interfaces (IF-MIB) and CPU/memory (HOST-RESOURCES where present).
  • Session counts, HA state, and policy stats are vendor-specific — Fortinet 12356, Palo Alto 25461, pfSense BSD/UCD.
  • Session-table saturation is the key firewall-specific alert the standard MIBs can't see.
  • Secure SNMP tightly on a security device: v3 or random community + source ACL, read-only.
  • For independent off-box checks, see external monitoring with ostr.io.

Monitor it from outside the network

SNMP only tells you a box is healthy while something is still asking. ostr.io polls your endpoints externally and fires email + SMS alerts the moment a reading crosses your line — or the agent goes silent.