Support Multiple NAT Mappings per External IP (Port Address Translation / Port Forwarding) #447

New Issue

MrUnknownDE · 2026-04-05T16:33:08+02:00

MrUnknownDE commented

2026-04-05 16:33:08 +02:00

Originally created by @bradmoutoux on 1/29/2026

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

*Originally created by @bradmoutoux on 1/29/2026* ### 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_

Sign in to join this conversation.

Branches Tags

main

21455-sql-indexes-audit

21357-register-model-actions

feature

20924-plugin-ui-components

21766-improve-test-coverage-for-sortable-table-columns

21157-export-template-public-models

21025-pre-render-config-contexts

21364-swagger

feature-ip-prefix-link

20911-dropdown-3

fix_module_substitution

21160-filterset

20911-dropdown-2

20044-elevation-stuck-lightmode

7604-filter-modifiers-v3

20660-script-load

19724-graphql

14884-script

19720-macaddress-interface-generic-relation

fix-19669-api-image-download

7604-filter-modifiers

19275-fixes-interface-bulk-edit

fix-17794-get_field_value_return_list

11507-show-aggregate-and-rir-on-api

9583-add_column_specific_search_field_to_tables

No Label complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium complexity: medium netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox netbox status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog status: backlog type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature type: feature

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github/netbox#447