Overlapping/Multiple NAT Support #971

@cslingerland commented on GitHub (Sep 13, 2018):

What if you were to add a "destination" IP field for the NATs. Then you could have multiple NATs sourcing from a single IP, and you'd be able to tell the difference based on the destination.

@cslingerland commented on GitHub (Sep 13, 2018): What if you were to add a "destination" IP field for the NATs. Then you could have multiple NATs sourcing from a single IP, and you'd be able to tell the difference based on the destination.

adam commented

@achard commented on GitHub (Jul 13, 2019):

Not sure how I feel about this. The outside-to-inside mapping is currently one-to-one. Relaxing this constraint so that multiple outside IPs can share a single inside IP opens the door for ambiguity. If A and B are both outside IPs for C, then we have no way of discerning what our outside IP will be in a scenario where we only know C.

I would point out that the ambiguity you are talking about is already there in the real world that is being modelled. If you only know C, and only one of the outside NAT addresses is listed in Netbox, somebody looking at Netbox may not realise that there are other addresses that could be a NAT outside address for this inside address.

This seems pretty straight forward on the surface.. change the OneToOneField to a ForeignKey.. plus the UI changes to accommodate multiple values :/

@achard commented on GitHub (Jul 13, 2019): > Not sure how I feel about this. The outside-to-inside mapping is currently one-to-one. Relaxing this constraint so that multiple outside IPs can share a single inside IP opens the door for ambiguity. If A and B are both outside IPs for C, then we have no way of discerning what our outside IP will be in a scenario where we only know C. I would point out that the ambiguity you are talking about is already there in the real world that is being modelled. If you only know C, and only one of the outside NAT addresses is listed in Netbox, somebody looking at Netbox may not realise that there are other addresses that could be a NAT outside address for this inside address. This seems pretty straight forward on the surface.. change the OneToOneField to a ForeignKey.. plus the UI changes to accommodate multiple values :/

adam commented

@vsvetlov commented on GitHub (Nov 26, 2019):

Hello,

@jeremystretch
As a temp solution, I would suggest updating a list of the roles for IP address object type with something like:

Static NAT
Dynamic NAT
The reason for it is that a NAT IP address is usually served by a network device (router or firewall) and should be assigned to its interface but this use case is not covered by VIP, Secondary or HSRP roles.

@vsvetlov commented on GitHub (Nov 26, 2019): Hello, @jeremystretch As a temp solution, I would suggest updating a list of the roles for IP address object type with something like: - Static NAT - Dynamic NAT The reason for it is that a NAT IP address is usually served by a network device (router or firewall) and should be assigned to its interface but this use case is not covered by VIP, Secondary or HSRP roles.

adam commented

@JNR8 commented on GitHub (Feb 24, 2020):

Did this ever get implemented?

We have soo many instances of multuiple outside IPs NAT'ing to a single Inside I which just can;t be documented in NetBox.

I have been trying to get colleauges to adopt NetBox as a documentation source for years now and they will not buy into it if it can't document what is percevied to be (rightly or wrongly) a standard within the industry.

@jeremystretch any chance this can be be revisited?

@JNR8 commented on GitHub (Feb 24, 2020): Did this ever get implemented? We have soo many instances of multuiple outside IPs NAT'ing to a single Inside I which just can;t be documented in NetBox. I have been trying to get colleauges to adopt NetBox as a documentation source for years now and they will not buy into it if it can't document what is percevied to be (rightly or wrongly) a standard within the industry. @jeremystretch any chance this can be be revisited?

adam commented

@JNR8 commented on GitHub (Feb 24, 2020):

To add to my issues, I also have 1:Many NATs that route to different internal IPs fro a single external IP based on the service (port number) that is used. I would like to be able to respresent this also.

@JNR8 commented on GitHub (Feb 24, 2020): To add to my issues, I also have 1:Many NATs that route to different internal IPs fro a single external IP based on the service (port number) that is used. I would like to be able to respresent this also.

adam commented

@achard commented on GitHub (Apr 27, 2020):

This is not just an issue for Overloaded NATs. It seems a little like you have made a decision that static 1:1 NAT is the only legitimate use of NAT.

The world I am trying to model in Netbox is AWS. I need to be able to assign Elastic IPs (Which are essentially DNATs) to VPC addresses. Sometimes an internal address will have multiple EIPs. I dont think its Netbox's job to resolve the above mentioned ambiguity.

@achard commented on GitHub (Apr 27, 2020): This is not just an issue for Overloaded NATs. It seems a little like you have made a decision that static 1:1 NAT is the only legitimate use of NAT. The world I am trying to model in Netbox is AWS. I need to be able to assign Elastic IPs (Which are essentially DNATs) to VPC addresses. Sometimes an internal address will have multiple EIPs. I dont think its Netbox's job to resolve the above mentioned ambiguity.

adam commented

@agowa commented on GitHub (Jun 10, 2020):

We're also having this issue right now.
The NAT types nearly everybody is using today are NAT-PAT (RFC 3022) and NAT-PT (RFC 2766), basically a many to many relationship that we want to store within Netbox. A literal NAT (RFC 1631) is mostly the exception.

I therefore propose:

A new Defineable list of Layer 4 Protocols (including e.g. TCP, UDP, SCTP)
Redefine all NAT mappings into a ip/service mapping e.g. Public IP 198.51.100.1 and Internal IP 10.0.0.1 from will become: 198.51.100.1:TCP-0 until 198.51.100.1:TCP-65535 mapped to 10.0.0.1:TCP-0 until 198.51.100.1:TCP-65535 (same for UDP and SCTP).

A mapping within the database could look like this internally:
Table 1: Defined Services including there Protocol Identifier (full list e.g. 6 for TCP)

Table 2: IPv6 Prefixes (IPv4 addresses could be stored as IPv4-Mapped Addresses for simplicity) with all other attributes they currently have (like unicast/anycast status, associated interface, ...) (This is the simplest option that allows to create NAT-PT relationships later, and the UI can simply derive the IPv4 addresses from that)

Table 3 (NAT-Mappings): With these attributes:

Inside IP
Inside Port
Protocol ID (Layer 4 Protocol ID) if NULL (undefined) represents a RFC 1631 NAT (Network address is translated independently of the Layer 4 Protocol)
(Maybe also) Boolean ALG support flags for (SIP, FTP, ...)
Type: SNAT/DNAT/both (stores if either source , destination or both addresses are translated)
Outside IP
Outside Port

Constraints:

If Protocol ID is NULL also Outside Port and Inside Port should be NULL.
Inside Port and Outside Port could be larger than 65535 for non TCP/UDP protocols (e.g. Protocol ID is neither 6 nor 17), it is however reasonable to let this part open for plugins/customizations

Note:

It is required that IPv4 Addresses are stored within the same table as IPv6 addresses, for simplicity and for a cleaner data structure they should be stored as IPv4-Mapped Addresses. The UI could just convert them to there "old representation" (in fact even css should be able to do that).

.ipv4mappedv6-to-v4 { 
  width : 100px;
  overflow:hidden;
  display:inline-block;
  direction: rtl;
  white-space: nowrap;
}

@agowa commented on GitHub (Jun 10, 2020): We're also having this issue right now. The NAT types nearly everybody is using today are NAT-PAT (RFC 3022) and NAT-PT (RFC 2766), basically a many to many relationship that we want to store within Netbox. A literal NAT (RFC 1631) is mostly the exception. I therefore propose: * A new Defineable list of Layer 4 Protocols (including e.g. TCP, UDP, SCTP) * Redefine all NAT mappings into a ip/service mapping e.g. Public IP 198.51.100.1 and Internal IP 10.0.0.1 from will become: 198.51.100.1:TCP-0 until 198.51.100.1:TCP-65535 mapped to 10.0.0.1:TCP-0 until 198.51.100.1:TCP-65535 (same for UDP and SCTP). A mapping within the database could look like this internally: Table 1: Defined Services including there Protocol Identifier ([full list](https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml) e.g. 6 for TCP) Table 2: IPv6 Prefixes (IPv4 addresses could be stored as [IPv4-Mapped Addresses](rfc5156#section-2.2) for simplicity) with all other attributes they currently have (like unicast/anycast status, associated interface, ...) (This is the simplest option that allows to create NAT-PT relationships later, and the UI can simply derive the IPv4 addresses from that) Table 3 (NAT-Mappings): With these attributes: * Inside IP * Inside Port * Protocol ID (Layer 4 Protocol ID) if NULL (undefined) represents a RFC 1631 NAT (Network address is translated independently of the Layer 4 Protocol) * (Maybe also) Boolean ALG support flags for (SIP, FTP, ...) * Type: SNAT/DNAT/both (stores if either source , destination or both addresses are translated) * Outside IP * Outside Port Constraints: * If Protocol ID is NULL also Outside Port and Inside Port should be NULL. * Inside Port and Outside Port could be larger than 65535 for non TCP/UDP protocols (e.g. Protocol ID is neither 6 nor 17), it is however reasonable to let this part open for plugins/customizations Note: * It is required that IPv4 Addresses are stored within the same table as IPv6 addresses, for simplicity and for a cleaner data structure they should be stored as IPv4-Mapped Addresses. The UI could just convert them to there "old representation" (in fact even css should be able to do that). ``` .ipv4mappedv6-to-v4 { width : 100px; overflow:hidden; display:inline-block; direction: rtl; white-space: nowrap; } ```

adam commented

@BatmanAMA commented on GitHub (Aug 11, 2020):

to add to the support, we have many services that are offered internally to multiple private networks managed by different groups and those services are natted into their networks - documenting this mass of nats is critical to being able to support it and even more critical to automating DNS management

@BatmanAMA commented on GitHub (Aug 11, 2020): to add to the support, we have many services that are offered internally to multiple private networks managed by different groups and those services are natted into their networks - documenting this mass of nats is critical to being able to support it and even more critical to automating DNS management

adam commented

@noide35 commented on GitHub (Feb 18, 2021):

Hello,

no news for this request ?
I currently have the same need which is NOT PAT but be able to NAT one real/inside IP to multiple outside/natted IP.
So this is not PAT but NAT depending on the external network/isp/view. And it is the subject of the first message of this issue.

So in that case we still have a one-to-one IP mapping regarding the outside IP.
To do that, we need to be able to have a list of outside NAT IP in the Real IP. The opposit of today where we indicate a real/inside IP in the outside one.

@noide35 commented on GitHub (Feb 18, 2021): Hello, no news for this request ? I currently have the same need which is NOT PAT but be able to NAT one real/inside IP to multiple outside/natted IP. So this is not PAT but NAT depending on the external network/isp/view. And it is the subject of the first message of this issue. So in that case we still have a one-to-one IP mapping regarding the outside IP. To do that, we need to be able to have a list of outside NAT IP in the Real IP. The opposit of today where we indicate a real/inside IP in the outside one.

adam commented

@dmoranf commented on GitHub (Jun 1, 2021):

Hi,

Same use case here, it would be great if we can associate and have a list of multiple inside/outside NATs for a unique real IP since we are doing different statics NAT (1:1) for different source networks / clients.

@dmoranf commented on GitHub (Jun 1, 2021): Hi, Same use case here, it would be great if we can associate and have a list of multiple inside/outside NATs for a unique real IP since we are doing different statics NAT (1:1) for different source networks / clients.

adam commented

@agowa commented on GitHub (Jul 4, 2021):

Is everything ok within netbox-community? There are so many deleted comments.
Was an account of the organization hacked?

@agowa commented on GitHub (Jul 4, 2021): Is everything ok within netbox-community? There are so many deleted comments. Was an account of the organization hacked?

adam commented

@jeremystretch commented on GitHub (Jul 4, 2021):

Per our contributing policy, comments with no substance or which do not relate to the topic at hand are removed to preserve the conversation's focus.

@jeremystretch commented on GitHub (Jul 4, 2021): Per our contributing policy, comments with no substance or which do not relate to the topic at hand are removed to preserve the conversation's focus.

adam commented

@apellini commented on GitHub (Sep 14, 2021):

Also for me this feature could be useful.

I have multiple customer that I see using NAT 1:1 but Customer sees my services with different NAT IP of my service.

For example:

Service A Real IP on VRF PROD: 10.1.1.1
NAT IP Service A on VRF CustomerA: 10.20.20.1
NAT IP Service A on VRF CustomerB: 10.20.30.1

So I need to correlate 10.20.20.1 and 10.20.30.1 to 10.1.1.1 so I could have the correct NAT Table represented on NetBox.

Thanks in advance. If I could help tell me.

@apellini commented on GitHub (Sep 14, 2021): Also for me this feature could be useful. I have multiple customer that I see using NAT 1:1 but Customer sees my services with different NAT IP of my service. For example: Service A Real IP on VRF PROD: 10.1.1.1 NAT IP Service A on VRF CustomerA: 10.20.20.1 NAT IP Service A on VRF CustomerB: 10.20.30.1 So I need to correlate 10.20.20.1 and 10.20.30.1 to 10.1.1.1 so I could have the correct NAT Table represented on NetBox. Thanks in advance. If I could help tell me.

adam commented

@maw1146 commented on GitHub (Nov 2, 2021):

Hi Guys,
why my comment was deleted? I have just asked if there was any update on this case...

@maw1146 commented on GitHub (Nov 2, 2021): Hi Guys, why my comment was deleted? I have just asked if there was any update on this case...

adam commented

@jeremystretch commented on GitHub (Nov 2, 2021):

Per the contributing guide:

Only comment on an issue if you are sharing a relevant idea or constructive feedback. Do not comment on an issue just to show your support (give the top post a 👍 instead) or ask for an ETA. These comments will be deleted to reduce noise in the discussion.

If there were any updates on this issue, they would appear here. There is no reason to ask.

@jeremystretch commented on GitHub (Nov 2, 2021): Per the [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md): > Only comment on an issue if you are sharing a relevant idea or constructive feedback. **Do not** comment on an issue just to show your support (give the top post a :+1: instead) or ask for an ETA. These comments will be deleted to reduce noise in the discussion. If there were any updates on this issue, they would appear here. There is no reason to ask.

adam commented

@jsenecal commented on GitHub (Dec 3, 2021):

As discussed over in Slack, I would be willing to take ownership of this Feature Request if contributions are accepted.

@jsenecal commented on GitHub (Dec 3, 2021): As discussed over in Slack, I would be willing to take ownership of this Feature Request if contributions are accepted.

adam commented