Why Firewall Rule Reviews Need NetBox Context — And How to Add It

Most firewall change reviews happen in a vacuum. A reviewer sees source 10.42.7.0/24, destination 203.0.113.5, port 443 — and has to decide whether to approve it without knowing whether those addresses are production, DMZ, decommissioned, or someone’s home lab. That context already exists in NetBox. It just isn’t where the reviewer is looking.

The review gap

NetBox is the dominant open-source network source of truth. Thousands of enterprises run it. It knows every prefix, every VRF, every site, and every device that has an IP. And yet, when a reviewer looks at a proposed firewall rule, none of that shows up.

The consequences are predictable. Rules get approved for IPs that don’t exist anymore. Rules get denied because a reviewer cannot tell whether a subnet is production or test. Reviewers tab-switch between the change ticket and NetBox, pasting IPs into the NetBox search bar one at a time, losing flow. Some just wave things through because the context-gathering cost is too high.

Inline context fixes this. When the prefix, VRF, tenant, and nearest device show up next to each source and destination IP in the rule, approval decisions get faster and more accurate.

Five situations where NetBox context changes the decision

These are cases we have seen during real change reviews where having NetBox data inline flipped the outcome:

1. Ghost subnets. A rule references 172.16.10.0/24, a subnet that was decommissioned eight months ago. NetBox knows the prefix is Status: Deprecated. Without that signal, the rule gets approved and sits in the firewall forever.
2. Tenant crossing. Source is tagged in NetBox under tenant TenantA; destination is TenantB. A reviewer sees the tenant mismatch immediately and asks why cross-tenant traffic is needed.
3. Wrong VRF. Source and destination are in different VRFs with no transit. The rule would never work in production and should be rejected before anyone touches the firewall.
4. Specificity check. A rule targets 10.0.0.0/8 when NetBox shows the relevant production prefix is 10.42.7.0/24. Tightening the scope takes 30 seconds at review time; doing it six months later during a rulebase audit takes days.
5. Device drift. The FwChange firewall being changed is linked to a NetBox device marked Status: Planned or Inventory. The reviewer spots that the device is not in production yet and flags the timing.

None of these are edge cases. They show up in roughly one in twenty reviews for any organization with more than fifty firewalls.

How to connect NetBox to FwChange in 5 steps

The integration is read-only and ships with FwChange today. Setup is under 5 minutes.

1. Create a read-only NetBox API token. In NetBox: Admin → API Tokens → Add. Uncheck Write Enabled. Set an expiry if your policy requires one. Copy the token.
2. Add the connector in FwChange. Dashboard → Integrations → IPAM → Add Connector. Enter your NetBox base URL and the token. Leave Verify SSL on unless you run NetBox with a self-signed certificate.
3. Test the connection. Click Test. FwChange calls NetBox’s /api/status/ endpoint, confirms the version, and moves the connector to ACTIVE.
4. Link firewalls to NetBox devices (optional). On any FwChange firewall, set ipamDeviceId to its NetBox device ID. The review sidebar then shows the device’s site, rack, serial, and primary IP.
5. Open a pending change. The NetBox Context card appears in the right sidebar. Every source and destination IP in the proposed rule gets resolved to its smallest enclosing NetBox prefix, tenant, and nearest device.

What the integration does not do

It is worth being explicit about the boundaries.

• No writes to NetBox. The token is read-only. FwChange never creates, updates, or deletes NetBox records. Your source of truth stays yours.
• No drift reconciliation. If firewall reality diverges from NetBox, FwChange shows the NetBox view but does not try to fix either side. NetBox Assurance already handles drift; we stay in the change-review lane.
• No bulk sync. There is no background job pulling your entire NetBox inventory into FwChange. Data is fetched on demand per review, cached for 5 minutes, and discarded.

Security model

The API token is encrypted at rest with AES-256-GCM using the FwChange ENCRYPTION_KEY environment variable. Only the organization that created a connector can use it; tokens never cross tenant boundaries.

Responses are cached in Redis for 5 minutes per connector, keyed by connector ID. When a connector is disabled or deleted, the cache is invalidated immediately so a reactivated connector fetches fresh data.

If NetBox is unreachable, the sidebar degrades gracefully — you see an inline error per failed lookup, and the rest of the review screen continues to work. IPAM downtime never blocks rule approval.

Try it

If you already run NetBox, the setup cost is five minutes and the value is per-reviewer, per-review, forever. If you run NetBox Cloud, point the connector at your tenant URL. If you want to evaluate without risk, NetBox publishes a public demo at https://demo.netbox.dev that you can connect to with a free read-only account.