How to Save Public Floating IPs on Nutanix: The Native Way

Routing outbound traffic from a Nutanix VPC can consume public IP addresses quickly. Each VPC receives its own external address when internet egress is enabled. In environments where multiple VPCs coexist this becomes wasteful and adds operational noise. Most workloads do not need a dedicated public exit point. They only need a clean and predictable path to a shared egress node.

A companion article called “The Offroad Way” will cover how to complement this architecture with an internal virtual firewall running inside a VPC. This pattern provides NAT capabilities and Floating IP handling that are not currently available natively in Flow Networking. I will update this page with the link as soon as it is published.

A better approach is to centralize egress and forward all outbound traffic to a single firewall or egress VM. Nutanix Flow Networking supports this model with route forwarding. It removes the need for a public IP on every VPC gateway and keeps the overall network model easier to understand when the environment scales.

Why VPCs consume too many public IPs

When a VPC is configured for internet egress Nutanix assigns:

• one public IP for the Flow Gateway
• additional public IPs for services exposed with Floating IPs

Repeating this configuration across multiple VPCs results in unnecessary consumption. For each VPC you lose:

• one public IP for its Flow Gateway
• one public IP for each exposed service

When the number of VPCs grows the public IP footprint grows with it. Most applications do not need direct exposure. They only need a predictable path out.

Using a Transit VPC as the central egress point

A Transit VPC hosts the only public external network in the environment. Individual VPCs keep private addressing and forward outbound traffic to the Transit VPC. This centralizes NAT, simplifies routing and avoids public IP consumption at the VPC layer.

Inside the Transit VPC you define a private addressing plan dedicated to routing across VPCs. A common layout is:

• Transit VPC external routable range 10.10.0.0/16
• each VPC uses a slice such as 10.10.x.0/24
• each VPC declares its slice in External Routable IP Addresses
• the Transit VPC declares the full 10.10.0.0/16

This makes routing deterministic. The Transit VPC knows how to reach every internal VPC. Each VPC inherits a predictable routing identity based on its x value.

When exposing a service publicly you assign the Floating IP in the Transit VPC and point it to the internal address. For example:

• Floating IP 87.112.12.13
• Destination 10.10.4.56 inside a VPC

This keeps all VPCs clean and avoids configuring public external networks outside of the Transit VPC.

Why this design is more efficient

Without a Transit VPC each VPC requires:

• a public IP for its Flow Gateway
• a second public IP for each exposed service

With the Transit VPC:

• only the Transit VPC consumes public IPs
• individual VPCs remain private
• NAT and ingress are centralized
• routing stays predictable within the 10.10.0.0/16 plan

It keeps cost under control and removes architectural complexity that usually appears when every VPC has its own NAT boundary.

I have used this model in customer environments where multiple VPCs needed to be aggregated under a shared Transit VPC, as well as in NKP deployments where several clusters required a predictable and centralized egress point. In both scenarios the Transit VPC kept the layout clean even as the number of VPCs grew or when external exposure had to be funneled through a single controlled gateway.

Strengthening the design with Flow Network Security

The Native Way works even better when combined with Flow Network Security. Once all VPCs follow a predictable 10.10.x.0/24 structure you can apply lightweight east west controls that reduce the attack surface without modifying the routing model.

Flow Network Security adds:

• basic workload isolation
• a simple allow list for internal services
• protection against accidental cross VPC traffic
• a consistent security layer across the environment

This is not full microsegmentation. It is a minimal and pragmatic layer that reinforces the Transit VPC architecture with almost no operational overhead. A separate article will cover deeper segmentation using Categories.

One Feature That Would Make This Even Cleaner

A useful enhancement for this model would be the option to assign Floating IPs directly to a Flow Gateway and configure NAT rules from a dedicated tab inside the VPC interface. This would align the workflow with the clarity already present in Flow Networking and make inbound and outbound mapping even more intuitive. The platform already provides all the building blocks for clean routing and centralized egress. This addition would further streamline the user experience.

Adding a no NAT external network to the Transit VPC

The Transit VPC can also host a second external network in no NAT mode. This allows workloads inside VPCs to reach internal management services such as Prism Central, NDB, NKP or hypervisor networks without translation. It also provides the datacenter routing device with a single point to reach all VPCs.

To configure the no NAT external network you define it as a full External Network identical to the NAT enabled one but with NAT disabled. Nutanix expects all parameters of the real datacenter network:

• VLAN ID
• subnet address
• subnet mask
• Number of Active Hosts
• an IP pool for the Flow Gateway

If the physical management network is 192.168.10.0/24 the no NAT external network must be configured as 192.168.10.0/24 on the same VLAN. You expose a small pool such as 192.168.10.50 to 192.168.10.52 since only the Flow Gateway requires addresses.

Routing inside the Transit VPC follows:

• NAT external network uses the default route 0.0.0.0/0
• no NAT external network advertises only the required internal networks such as Prism Central, NDB, NKP and hypervisor management

On the datacenter routing device you configure:

• route 10.10.0.0/16 with next hop equal to the Flow Gateway IP on the management VLAN

This gives the core infrastructure reachability into all VPCs in the 10.10.x.0/24 ranges.

Important configuration detail

When associating the no NAT external subnet to the Transit VPC set “Number of Active Hosts” to 1 in the External Gateway Configuration section. This parameter defaults to 2. Leaving it unchanged would create multiple active Flow Gateways and require upstream load balancing or introduce asymmetric routing. Setting it to 1 ensures the no NAT path uses a single gateway and keeps routing predictable. This value cannot be modified later.

Resulting architecture

The Transit VPC becomes a controlled ingress and egress hub. Public exposure and NAT are centralized. Management traffic flows through a dedicated no NAT external network. Individual VPCs remain private and deterministic within the 10.10.0.0/16 routing plan.

This model follows the same principles commonly seen in Nutanix validated architectures for multi VPC and shared services environments. It is a clean and scalable approach that aligns naturally with hub and spoke models and works well in customer environments and NKP topologies.