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

Allow NAT inside address without IPAM entry of itself #1715

New Issue
Closed
opened 2025-12-29 16:34:40 +01:00 by adam · 2 comments
adam commented 2025-12-29 16:34:40 +01:00
Owner
Copy Link

Originally created by @CDawson1 on GitHub (May 3, 2018).

Issue type

[X ] Feature request

Environment

  • Python version: 2.7.12
  • NetBox version: 2.3.1

Description

For the sake of discussion, my public IP is what I want to populate with a private IP NAT inside.

When creating an public IP address that has a need to reference a private NAT, that NAT seems to require it's own entry in IPAM before it can be populated as a NAT. By default, that private IP entry would/should also have a NAT that references the public.

As such, it's a recursive entry.

I don't want/need the private IP to have its own listing. We don't own this space, but our environment is such that we need to reference it. It seems unnecessary to have two sides of the same coin represented.

Essentially this seems to require this field to be an arbitrary field, but it should still be displayed on the main table view and searchable.

While a custom field could fit the bill, that seems to require additional changes that essentially duplicate what the NAT IP inside field already is, in addition to additional work required to get the displays correct.

Is this something that's easily changed without compromising any existing use of this field?

Originally created by @CDawson1 on GitHub (May 3, 2018). ### Issue type [X ] Feature request ### Environment * Python version: 2.7.12 * NetBox version: 2.3.1 ### Description For the sake of discussion, my public IP is what I want to populate with a private IP NAT inside. When creating an public IP address that has a need to reference a private NAT, that NAT seems to require it's own entry in IPAM before it can be populated as a NAT. By default, that private IP entry would/should also have a NAT that references the public. As such, it's a recursive entry. I don't want/need the private IP to have its own listing. We don't own this space, but our environment is such that we need to reference it. It seems unnecessary to have two sides of the same coin represented. Essentially this seems to require this field to be an arbitrary field, but it should still be displayed on the main table view and searchable. While a custom field could fit the bill, that seems to require additional changes that essentially duplicate what the NAT IP inside field already is, in addition to additional work required to get the displays correct. Is this something that's easily changed without compromising any existing use of this field?
adam closed this issue 2025-12-29 16:34:40 +01:00
adam commented 2025-12-29 16:34:41 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 4, 2018):

By default, that private IP entry would/should also have a NAT that references the public.

You'll need to create both the outside and inside IP addresses, but only the outside-to-inside relationship needs to be defined.

@jeremystretch commented on GitHub (May 4, 2018): > By default, that private IP entry would/should also have a NAT that references the public. You'll need to create both the outside and inside IP addresses, but only the outside-to-inside relationship needs to be defined.
adam commented 2025-12-29 16:34:41 +01:00
Author
Owner
Copy Link

@CDawson1 commented on GitHub (May 4, 2018):

Ugh...so much for a discussion...

While that’s what NEEDS to happen, that doesn’t mean it should.

So we need to create an entry that has no value other than needing to exist to only be referenced somewhere else. How is that logical?

At the least, something to hide that IPAM entry then perhaps? It’s information that only takes up space, and does require additional information to indicate its purpose...so in essence a double entry.

@CDawson1 commented on GitHub (May 4, 2018): Ugh...so much for a discussion... While that’s what NEEDS to happen, that doesn’t mean it should. So we need to create an entry that has no value other than needing to exist to only be referenced somewhere else. How is that logical? At the least, something to hide that IPAM entry then perhaps? It’s information that only takes up space, and does require additional information to indicate its purpose...so in essence a double entry.
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#1715
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?