Netbox: Overlapping/Multiple NAT Support

[engageant]

Issue Type: Feature Request

Currently, netbox only allows a 1:1 mapping of inside IPs to outside IPs. If an inside IP is homed to several ISPs each with their own address space, we cannot accurately represent the NAT configuration in netbox:
IP address with this NAT IP (inside) already exists.
Currently, what I'm doing is adding the primary outside IP as the NAT address, then I add the secondary outside IP as an additional IP on the interface - not ideal. Would it be possible to extend the NAT functionality to allow one-to-many (inside to outside) mappings?

[jeremystretch]

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.

[engageant]

Hmmm...any ideas on how to better accomplish this with the functionality
already in place?

On Thu, Jun 1, 2017 at 4:38 PM Jeremy Stretch [e-mail]
wrote:

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.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/digitalocean/netbox/issues/1202#issuecomment-305613200,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADSI6pjvS53hw4LY0hOGeNlwwLNDg0huks5r_yE0gaJpZM4NfuDn
.

[traveler3468]

Thanks for getting me on the right discussion @jeremystretch. Sorry I missed it.
For me since this is a documentation tool I think it would be helpful to just be able to see that information.
IP C is NAT'd to both A and B, but for different destinations. On the IP address page for IP C you can look in the NAT (outside) section and see the IP's that it may be getting NAT'd to. But if you look at one of the outside addresses it will only be related to the one inside address

[cslingerland]

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.

[achard]

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 :/

[vsvetlov]

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.

[jennec]

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?

[jennec]

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.

[achard]

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.

[agowa338]

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;
}

[BatmanAMA]

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