Consuming Firewall and Network Metrics

Firewall and network metrics (throughput, CPU, active sessions, IPsec tunnel traffic) are a different data source from the Orka cluster metrics covered in Consuming Metrics from Prometheus. This page covers where firewall metrics come from, how to view them today, and how to pull them directly into your own monitoring stack.

What’s collected

MacStadium polls your firewall over SNMP and stores the results centrally. This is separate from, and not exposed through, the Orka cluster Prometheus endpoints (server, operator, node exporter) described in Consuming Metrics from Prometheus. Those endpoints cover your Orka cluster itself, not the firewall in front of it. Metrics collected:

Interface throughput: inbound and outbound octets per interface (for example Outside, Private-N), converted to bits/sec
CPU utilization: 1-minute and 5-minute averages
Active sessions: current connection count (a single aggregate gauge across all services, not broken out per service)
IPsec / VPN tunnel traffic: inbound and outbound octets per tunnel

Only traffic that crosses the firewall (outside traffic, inter-VLAN traffic) is captured this way. Traffic that stays internal to your environment (node-to-node, node-to-storage) doesn’t appear here.

Viewing it today: the portal networking graph

The MacStadium portal’s networking/bandwidth graph is built from this same collection pipeline. For most accounts, no setup is required: the graph reflects your firewall’s SNMP data automatically.

Troubleshooting a blank or missing graph

If the portal graph is empty or missing data:

Confirm collection is actually running, not just failing to render. A blank graph usually means a portal display issue rather than lost data. The underlying metrics are frequently still being collected correctly. Contact support to confirm collection status for your firewall before assuming data loss.
Check whether your firewall is managed or self-managed. Managed firewalls (the default) are configured for SNMP collection by MacStadium directly; no customer action is needed. Self-managed firewall configurations require SNMP to be enabled and reachable from MacStadium’s collectors. See the next section if you’re on a self-managed config and haven’t set this up.
If the graph still doesn’t populate after confirming collection is healthy, contact support@macstadium.com with your service ID and the affected time range.

Self-managed firewalls: enabling collection

If you manage your own firewall configuration, MacStadium’s collectors need:

SNMP v2c enabled on the device (MacStadium’s collectors poll v2c; v3 isn’t currently used)
MacStadium’s collector source addresses permitted through your firewall’s own access rules:
- LAS: 207.254.72.76
- DUB: 208.83.0.66
- ATL: pending; check with your MacStadium contact for the current address
SNMP community string shared with MacStadium through a secure channel
UDP/161 reachable from MacStadium’s collector network

If you need to reconfigure your firewall to enable this, you can reach it directly over SSH or ASDM once you’ve established a VPN connection, using its LAN-side interface IP (typically 10.221.188.1 for Orka firewalls). Contact support@macstadium.com to coordinate enabling this.

Pulling firewall metrics into your own monitoring

If you want live firewall metrics in your own Prometheus, Grafana, or alerting instead of (or in addition to) the portal graph, you can scrape your firewall directly over SNMP (the same way MacStadium does), since you have SNMP-level visibility into your own device. This doesn’t depend on anything in the portal and gives you real PromQL access, your own retention, and your own alerting rules. MacStadium’s own retention on this pipeline is approximately 30 days; scrape it into your own stack if you need history beyond that.

A few things worth knowing before you build on the OIDs below:

The active-sessions OID returns a single aggregate gauge, not a per-service breakdown.
The IPsec tunnel OIDs here are the 64-bit high-capacity counters, not the 32-bit versions of the same metric. Use the ones shown here to avoid counter wraparound under sustained throughput.
Outside and Private-1 interfaces mirror each other on Orka firewalls, so summing both double-counts traffic. For bandwidth questions, use Outside alone.
The portal graph is a 5-minute average built from a 60-second poll. Scraping at a shorter interval (for example the 30s below) will show peaks 1.5–2.4x higher than the portal displays for the same window. That’s expected, not a discrepancy to chase.

What you’ll need

SNMP read access to your firewall (already available if you manage your own firewall config; contact support to request read-only SNMP community credentials if you’re on a managed firewall and want direct access)
A collector: either telegraf’s SNMP input plugin writing into your own Prometheus/InfluxDB, or Prometheus’s snmp_exporter scraped directly by your own Prometheus

Example: telegraf SNMP input

[[inputs.snmp]]
  agents = ["udp://<firewall-ip>:161"]
  version = 2
  community = "<your-read-only-community-string>"
  interval = "30s"

  # CISCO-PROCESS-MIB::cpmCPUTotal1minRev / cpmCPUTotal5minRev -- these are table columns, not
  # plain scalars, so they need a CPU instance index appended. `.1` is correct for single-CPU
  # ASA hardware; on multi-core platforms (for example Firepower), walk cpmCPUTotalTable first
  # to confirm your device's actual instance index.
  [[inputs.snmp.field]]
    name = "cpu_used_1m"
    oid = "1.3.6.1.4.1.9.9.109.1.1.1.1.7.1"

  [[inputs.snmp.field]]
    name = "cpu_used_5m"
    oid = "1.3.6.1.4.1.9.9.109.1.1.1.1.8.1"

  # CISCO-FIREWALL-MIB::cfwConnectionStatValue, a single hardcoded instance (service 40, type 6),
  # not a table walk -- one aggregate current-connections gauge, not a per-service breakdown
  [[inputs.snmp.field]]
    name = "connections_in_use"
    oid = "1.3.6.1.4.1.9.9.147.1.2.2.2.1.5.40.6"

  # IF-MIB::ifHCInOctets / ifHCOutOctets, tagged with ifDescr so each row is labeled by interface
  [[inputs.snmp.table]]
    name = "interface"
    index_as_tag = true

    [[inputs.snmp.table.field]]
      name = "interface_name"
      oid = "IF-MIB::ifDescr"
      is_tag = true

    [[inputs.snmp.table.field]]
      name = "in_octets"
      oid = "1.3.6.1.2.1.31.1.1.1.6"

    [[inputs.snmp.table.field]]
      name = "out_octets"
      oid = "1.3.6.1.2.1.31.1.1.1.10"

  # CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunHcInOctets / cipSecTunHcOutOctets (64-bit counters),
  # tagged with cipSecTunRemoteAddr for a per-tunnel peer label
  [[inputs.snmp.table]]
    name = "ipsec_tunnel"
    index_as_tag = true

    [[inputs.snmp.table.field]]
      name = "remote_addr"
      oid = "CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecTunRemoteAddr"
      is_tag = true

    [[inputs.snmp.table.field]]
      name = "tunnel_in_octets"
      oid = "1.3.6.1.4.1.9.9.171.1.3.2.1.27"

    [[inputs.snmp.table.field]]
      name = "tunnel_out_octets"
      oid = "1.3.6.1.4.1.9.9.171.1.3.2.1.40"

Point telegraf’s output at your own Prometheus (via outputs.prometheus_client) or your existing metrics backend.

Simpler alternative: total IPsec traffic, no per-tunnel breakdown

If you don’t need per-tunnel detail, a single tunnel count and combined in/out byte total is available as three scalars instead of a table walk:

  # CISCO-IPSEC-FLOW-MONITOR-MIB::cipSecGlobalActiveTunnels.0 / cipSecGlobalHcInOctets.0 / cipSecGlobalHcOutOctets.0
  [[inputs.snmp.field]]
    name = "ipsec_active_tunnels"
    oid = "1.3.6.1.4.1.9.9.171.1.3.1.1.0"

  [[inputs.snmp.field]]
    name = "ipsec_octets_in"
    oid = "1.3.6.1.4.1.9.9.171.1.3.1.4.0"

  [[inputs.snmp.field]]
    name = "ipsec_octets_out"
    oid = "1.3.6.1.4.1.9.9.171.1.3.1.17.0"

This is the same data the portal’s own IPsec total reflects, tunnel count and combined bytes across every tunnel on the device, not broken out individually. On HA firewall pairs, these values are synced between the active and standby unit, so either device reports the same number. This makes it the simplest thing to point a health check or alert at if you don’t need per-tunnel detail.

Example: Prometheus snmp_exporter

If you’d rather have your own Prometheus scrape the firewall directly instead of running telegraf as an intermediary, snmp_exporter is the standard alternative. Point a scrape job at the exporter with your firewall as the target, using the community string from the prerequisites above.

What you get

Once running, you have the same metric categories as the portal graph (throughput, CPU, sessions, IPsec tunnel traffic) as native series in your own Prometheus: queryable with PromQL, usable in your own Grafana dashboards, and able to drive your own alerting rules. Unlike the portal graph, this path is entirely yours to operate: your own retention, your own dashboards, no dependency on the portal rendering correctly.

MacStadium’s own collectors continue polling your firewall in parallel for the portal graph and for MacStadium’s proactive bandwidth monitoring. Running your own collector alongside this doesn’t conflict with or replace it.

Getting help

If you have questions about enabling collection, requesting SNMP credentials, or interpreting the metrics, contact MacStadium support.

MacStadium

Orka

MacStadium VDI

IaaS

Consuming Firewall and Network Metrics

What’s collected

Viewing it today: the portal networking graph

Troubleshooting a blank or missing graph

Self-managed firewalls: enabling collection

Pulling firewall metrics into your own monitoring

What you’ll need

Example: telegraf SNMP input

Simpler alternative: total IPsec traffic, no per-tunnel breakdown

Example: Prometheus snmp_exporter

What you get

Getting help

​What’s collected

​Viewing it today: the portal networking graph

​Troubleshooting a blank or missing graph

​Self-managed firewalls: enabling collection

​Pulling firewall metrics into your own monitoring

​What you’ll need

​Example: telegraf SNMP input

​Simpler alternative: total IPsec traffic, no per-tunnel breakdown

​Example: Prometheus snmp_exporter

​What you get

​Getting help

What’s collected

Viewing it today: the portal networking graph

Troubleshooting a blank or missing graph

Self-managed firewalls: enabling collection

Pulling firewall metrics into your own monitoring

What you’ll need

Example: telegraf SNMP input

Simpler alternative: total IPsec traffic, no per-tunnel breakdown

Example: Prometheus snmp_exporter

What you get

Getting help