How VPC NAT v2.0 Enables One‑Click Cross‑VPC Connectivity

VPC (Virtual Private Cloud) provides an isolated, customizable network space in public clouds, and the NAT gateway translates private IPv4 addresses to NAT IPs to enable inter‑VPC communication. In version 1.0, NAT rules were applied at the subnet level, requiring multiple API calls and rule entries whenever a new subnet was added, which increased configuration complexity and operational risk.

Control‑Plane Adjustments

The snat_rules table is extended with four new columns to record target VPC details, enabling the system to query and associate rules more efficiently:

src_vpc_uuid : source VPC UUID

dst_vpc_uuid : destination VPC UUID

cidr : CIDR blocks of the source VPC subnets (comma‑separated, e.g., 172.16.2.0/24,172.16.3.0/24)

vpc_cidr : a map of VNI to one or more destination subnet CIDRs, e.g., {"100":"172.16.0.0/24,172.16.1.0/24","200":"172.16.2.0/24"}

Rule‑Generation Changes

The NAT IP's VNI field changes from a single value to a comma‑separated string, allowing a rule to match all subnets belonging to the same VNI.

Each rule now includes the full set of destination subnets, eliminating the need for multiple per‑subnet entries.

Forwarding‑Plane Adjustments

A new vpc_vni parameter is added to support VPC‑level forwarding. When a packet reaches the gateway, the forwarding rule selects the appropriate NAT IP, uses the VNI to locate the target VM’s information, encapsulates the packet with VXLAN, and forwards it to the correct compute node.

Overall Forwarding Process

Two typical traffic scenarios are illustrated:

VM/Container access : The source VM’s packet is encapsulated by the compute node, sent to the VPC NAT gateway, which applies the snat_rule, rewrites the source IP to the destination VPC’s NAT IP, re‑encapsulates the packet, and forwards it to the target VPC’s compute node. The response follows the reverse path via the CCN gateway and NAT gateway.

Load‑Balancer VIP access : The packet is first sent to the VPC NAT gateway, then forwarded to the FNAT gateway, which routes it through the load balancer to the real server (RS) in the destination VPC; the return path mirrors the forward path.

Summary of Improvements

Supports one‑time VPC‑to‑VPC connectivity at VPC granularity.

Reduces the number of NAT rules, lowering configuration and operational costs.

Maintains compatibility with legacy subnet‑level calls.

Provides a clearer control‑plane design suitable for complex cross‑VPC scenarios.

Current NAT gateway already handles isolated VPC outbound, VPC‑to‑VPC, and isolated VPC‑to‑IDC use cases; future plans include DNAT support and security policy modules.