starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Multiple NAT Entries for one IP address (Port-Forwarding/PAT) #621

New Issue
Closed
opened 2025-12-29 16:23:54 +01:00 by adam · 4 comments
adam commented 2025-12-29 16:23:54 +01:00
Owner
Copy Link

Originally created by @nonsbe on GitHub (Jan 10, 2017).

Dear Jeremy,

Feature Request/Roadmap description:
It would be nice to have the ability to enter mutliple NAT lines in the IP address entry.
We currently have a pool of public IP addresses that are used for one-to-one NAT (which is already implemented) and another pool that is used for port-forwarding purposes.

For example:
Prefix: 1.1.1.0/28 - Public IP Pool for PAT/Port-Forwarding
IP Address: 1.1.1.1/28

Currently you can only assign one inside IP address to this entry.
A roadmap feature could be that you can choose the type of NAT used. Once you select the correct type -> Port-Forwarding. The input fields could change to something as

  • Outside Port: <TCP/UDP Port Number>
  • Inside IP Address: cross VRF capable (since the Public IP space is in another VRF as the customer internal IP addresses
  • Inside Port: <TCP/UDP Port Number>

An extra + sign to add a new port forwarding entry. In this manner it would easen the case to manage our public IPs and services being exposed to the internet.

Further comments or improvements are welcome.
Thank you for your time,
Kind Regards,
N. D.

Originally created by @nonsbe on GitHub (Jan 10, 2017). Dear Jeremy, **Feature Request/Roadmap description:** It would be nice to have the ability to enter mutliple NAT lines in the IP address entry. We currently have a pool of public IP addresses that are used for one-to-one NAT (which is already implemented) and another pool that is used for port-forwarding purposes. **For example:** Prefix: 1.1.1.0/28 - Public IP Pool for PAT/Port-Forwarding IP Address: 1.1.1.1/28 Currently you can only assign one inside IP address to this entry. A roadmap feature could be that you can choose the type of NAT used. Once you select the correct type -> Port-Forwarding. The input fields could change to something as - Outside Port: <TCP/UDP Port Number> - Inside IP Address: <IP Address> cross VRF capable (since the Public IP space is in another VRF as the customer internal IP addresses - Inside Port: <TCP/UDP Port Number> An extra **+** sign to add a new port forwarding entry. In this manner it would easen the case to manage our public IPs and services being exposed to the internet. Further comments or improvements are welcome. Thank you for your time, Kind Regards, N. D.
adam closed this issue 2025-12-29 16:23:54 +01:00
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Jan 10, 2017):

NetBox's role is in infrastructure management, e.g. IPAM and DCIM. We've recently introduced the ability to attach discrete L4 services to devices, but that's as far as we'll go. NetBox supports NAT mappings because it's crucial to the management of IP resources. Port address translation, however, crosses the boundary into policy management, which is out of scope for NetBox.

@jeremystretch commented on GitHub (Jan 10, 2017): NetBox's role is in infrastructure management, e.g. IPAM and DCIM. We've recently introduced the ability to attach discrete L4 services to devices, but that's as far as we'll go. NetBox supports NAT mappings because it's crucial to the management of IP resources. Port address translation, however, crosses the boundary into policy management, which is out of scope for NetBox.
adam commented 2025-12-29 16:23:55 +01:00
Author
Owner
Copy Link

@JNR8 commented on GitHub (Aug 15, 2018):

Its still possible to have more than one NAT rule pointing the same inside IP. So there is still a case for this in Netbox.

For example, we have multiple external IP addresses with NAT rules through to the same internal IP address. This is because multiple service types run on these devices which require dedicated external IP addressing.

Could you revisit this request please?

@JNR8 commented on GitHub (Aug 15, 2018): Its still possible to have more than one NAT rule pointing the same inside IP. So there is still a case for this in Netbox. For example, we have multiple external IP addresses with NAT rules through to the same internal IP address. This is because multiple service types run on these devices which require dedicated external IP addressing. Could you revisit this request please?
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@Hossy commented on GitHub (Jun 3, 2019):

I agree with @jennec. I would also ask that this issue be reconsidered from a PAT perspective. I don't think this is a policy issue. If this tool is going to manage IP addresses, I need to be able to document how those IPs are being used. The knowledge/documentation that they are used without the information answering "how?" is IMHO useless.

There needs to be a many-to-one and one-to-many (by port) relationship to establish proper documentation.

@Hossy commented on GitHub (Jun 3, 2019): I agree with @jennec. I would also ask that this issue be reconsidered from a PAT perspective. I don't think this is a policy issue. If this tool is going to manage IP addresses, I need to be able to document how those IPs are being used. The knowledge/documentation that they are used without the information answering "how?" is IMHO useless. There needs to be a many-to-one and one-to-many (by port) relationship to establish proper documentation.
adam commented 2025-12-29 16:23:56 +01:00
Author
Owner
Copy Link

@siddallhotmail commented on GitHub (Jul 25, 2019):

I agree with @Hossy .. in terms of IP management, we need to track which external IP & Service is mapped to which internal address, and potentially multiple addresses when you want to define a load-balanced PAT. The ability to store the information is essential to a solution design and IPAM management, could this feature request be reconsidered?

@siddallhotmail commented on GitHub (Jul 25, 2019): I agree with @Hossy .. in terms of IP management, we need to track which external IP & Service is mapped to which internal address, and potentially multiple addresses when you want to define a load-balanced PAT. The ability to store the information is essential to a solution design and IPAM management, could this feature request be reconsidered?
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#621
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?