---
type: Article
title: "Monitor Firewalls via SNMP"
description: "Watch a firewall's throughput, link state, session load, CPU and memory over SNMP — pfSense and FortiGate OIDs, and why to poll it from outside the edge."
resource: "https://snmp-monitoring.com/devices/firewall/"
tags: [devices, snmp]
timestamp: 2026-07-13T00:00:00Z
---

# 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.

![Diagram of an external SNMP poller reading IF-MIB interface counters and session OIDs from a firewall appliance across the internet](https://snmp-monitoring.com/img/devices/firewall-snmp-poll.webp)

## 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.

| Metric | OID | MIB / standard |
|---|---|---|
| Interface throughput (64-bit) | `1.3.6.1.2.1.31.1.1.1` (`ifXTable`: `ifHCInOctets`, `ifHCOutOctets`) | IF-MIB (RFC 2863) |
| Interface up/down + speed | `1.3.6.1.2.1.2.2.1` (`ifTable`: `ifOperStatus`, `ifSpeed`) | IF-MIB (RFC 2863) |
| Appliance name / model string | `1.3.6.1.2.1.1.1.0` (`sysDescr`) | MIB-II (RFC 1213) |
| Uptime since last reboot | `1.3.6.1.2.1.1.3.0` (`sysUpTime`) | MIB-II (RFC 1213) |
| Active sessions / connections | vendor-specific — consult the device MIB | vendor enterprise MIB |
| Throughput per policy, VPN state | vendor-specific — consult the device MIB | vendor enterprise MIB |

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](/sensors/network/interface-traffic.md). Whether a link is actually up is `ifOperStatus`, covered under [interface info](/sensors/network/interface-info.md); 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](/sensors/network/interface-errors.md) 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:
   ```bash
   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](/setup/custom-port.md).
- **Publish only the OIDs you poll** with an [OID allowlist](/setup/oid-allowlist.md) 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](/setup/troubleshooting.md) 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](/monitoring/double-durability.md): a watcher beyond your perimeter still sees the box when the box can't reach out.

[ostr.io Monitoring](https://ostr.io/service/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](/monitoring/alerts-email-sms.md) when an interface goes down, throughput flatlines, or the device stops responding — no internal collector to be stranded behind the very firewall that failed.

![Dashboard chart of firewall WAN throughput and active session count collected via SNMP with an alert threshold line](https://snmp-monitoring.com/img/devices/firewall-snmp-dashboard.webp)


## FAQ

**Is pfSense SNMP different from FortiGate SNMP?**
The standard parts are the same — both expose IF-MIB interface counters and the MIB-II system group, so your poller reads them identically. The difference is the vendor MIB: pfSense builds on FreeBSD's standards-based trees, while FortiGate publishes Fortinet's enterprise MIB for session tables and health. Load the right vendor MIB for the appliance you're polling.

**Which OID gives me the active session or connection count?**
That's a vendor-specific object, not a standard one, so it differs by platform and model. Walk your appliance's enterprise MIB to find the exact object rather than copying an OID from another brand — assuming one carries over is a common and misleading mistake.

**Can I safely enable SNMP on the WAN interface?**
Avoid it. Bind the SNMP service to your management interface, restrict it to your poller's IP, and use SNMPv3 if the device must be reached across untrusted links. Exposing a v2c community on the WAN hands an attacker a clear-text password and a map of your network.

**Do I need SNMP traps as well as polling?**
Polling gives you the steady time series for throughput, sessions and link state. Traps are useful for instant notification of discrete events, but they depend on the firewall being healthy enough to send them — which is exactly why external polling matters more for catching a device that has actually failed.

## Conclusion

SNMP firewall monitoring rests on two layers: portable standards — IF-MIB interfaces and the MIB-II system group — for throughput, link state and uptime, and each vendor's enterprise MIB for session counts and firewall-specific health. Whether you run pfSense SNMP or FortiGate SNMP, enable the agent on the management interface only, lock it down, and poll the counters that matter. Then put the real watcher outside the perimeter, because a firewall in trouble is the last device that can be trusted to raise its own alarm.