NetBox version

v4.4.10

Feature type

New functionality

Proposed functionality

NetBox currently enforces an implicit 1:1 relationship between external and internal IP addresses when modeling NAT. This prevents accurate representation of Port Address Translation (PAT) / port-forwarding, where a single public IP maps to multiple internal IPs differentiated by port, protocol, or service.

As NetBox has evolved into a central authoritative Source of Truth (SoT)—often used for audits, security reviews, and cross-system reconciliation—this limitation creates a structural gap in the data model. Organizations are forced to document these relationships outside of NetBox using custom fields, notes, or external systems, which breaks relational integrity and increases documentation drift.

The proposed functionality is to allow one external IP address to be associated with multiple internal IP addresses, optionally scoped by port and protocol. This would be a pure modeling enhancement, not a traffic-processing or enforcement feature.

NetBox would not evaluate flows, interpret firewall logic, or act as a policy engine. It would simply model real-world network relationships in a structured, queryable, and API-accessible manner—consistent with NetBox’s role as a system of record.

Use case

Our organization manages 94 active domains and 128 public IP addresses across multiple acquired business units, internally developed ERP and mobile applications, Citrix infrastructure, and Kemp load balancers. We are not a hosting or media provider; our public IP usage reflects standard enterprise application publishing requirements.

In practice, several public IPs in our environment:

• Forward different ports to different internal IPs

• Terminate on web servers hosting multiple sites

• Front load balancers that distribute traffic to multiple services

• Serve as the anchor point for DNS, firewall rules, and SSL/TLS certificates

NetBox currently provides no native way to model these 1:Many external-to-internal relationships. Workarounds such as custom fields or free-text notes do not scale and undermine NetBox’s value as a relational SoT. Attempts to use FHRP groups only work when internal IPs are not assigned to devices or VMs, which breaks accurate asset tracking.

Because of this limitation, we must maintain separate reconciliation processes for firewall rules, public DNS, internal DNS, and SSL mappings—introducing operational risk and audit complexity.

Allowing a single external IP to reference multiple internal IPs would enable NetBox to accurately document these relationships, reduce duplicate documentation, and preserve NetBox’s role as the authoritative system for network and application infrastructure.

Database changes

No response

External dependencies

No response