- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Public NAT Gateway Operation Guide
- Private NAT Gateway Operation Guide
- Practical Tutorial
- Enabling Cross-VPC Access to Public Network via Standard NAT Gateway
- Enabling Mutual Access between a Specified VPC Subnet and Public Network Resources via Private NAT Gateway
- Enabling Secure Mutual Access with Public Network via Public CLB and NAT Gateway
- Adjusting the Priorities of NAT Gateways and EIPs
- API Documentation
- FAQ
- Service Level Agreement
- Contact Us
- Glossary
- Release Notes and Announcements
- Product Introduction
- Purchase Guide
- Getting Started
- Public NAT Gateway Operation Guide
- Private NAT Gateway Operation Guide
- Practical Tutorial
- Enabling Cross-VPC Access to Public Network via Standard NAT Gateway
- Enabling Mutual Access between a Specified VPC Subnet and Public Network Resources via Private NAT Gateway
- Enabling Secure Mutual Access with Public Network via Public CLB and NAT Gateway
- Adjusting the Priorities of NAT Gateways and EIPs
- API Documentation
- FAQ
- Service Level Agreement
- Contact Us
- Glossary
Enabling Cross-VPC Access to Public Network via Standard NAT Gateway
Last updated: 2024-08-01 14:14:49
Use Cases
The user has established a NAT gateway in a VPC, and the CVM instances in the same VPC or other VPCs (including VPCs in the same region, cross-region VPCs, and cross-account VPCs) wish to access the public network through the NAT gateway.
Limits
The feature of cross-VPC access to the public network is currently supported only by Standard NAT Gateway but not by Traditional NAT Gateway.
The NAT routes of different VPCs cannot be simultaneously published to the Cloud Connect Network (CCN).
The Standard NAT Gateway is in beta testing. If you need to use it, please submit a ticket for request.
Configuration Principles
After the user creates a NAT gateway and configures the destination IP range as the public IP address and the next hop as the NAT route, the CVM instances in the same VPC can access the public network via the NAT route. Once the NAT route is published to the CCN, other VPCs associated with the CCN can also access the public network through the CCN and NAT.
Note:
The CCN is an independent product. Using it will incur related fees. For details, please refer to Billing Overview.
Use Process
Step 1: Creating a Standard NAT Gateway in the Beijing VPC
Log in to the NAT Gateway console. Refer to Creating NAT Gateway, to create a sample NAT gateway vpc_bj_nat.
Note:
The VPC where the NAT gateway is located cannot have a VPN gateway.
Step 2: Adding a Routing Policy
Log in to the Route Table console and create a routing policy in the route table of the sample gateway vpc_bj_nat for the Beijing VPC, such as the default route
0.0.0.0 with the next hop as the NAT gateway. For detailed operations, refer to Configuring Routes Pointing to NAT Gateway.At this time, the CVMs in the same VPC can access the public network through this route.
Step 3: Confirming the CVM in the Guangzhou VPC
Log in to the CVM console. Ensure that the Guangzhou VPC has a CVM instance, such as cvm_gz. If there are no CVMs, refer to Creating a CVM Instance.
Step 4: Creating and Joining a CCN
Log in to the VPC - CCN console. Refer to the documents Creating a CCN Instance and Associating Network Instances, to add the Beijing VPC with the NAT gateway and the Guangzhou VPC with the cvm_gz instance to the CCN. Refer to Associating Network Instances.
Note:
1. The CVM instances here can belong to a VPC in the same region, a cross-region VPC, or a cross-account VPC, without regional restrictions.
2. In terms of the process, you can first add the Beijing VPC to the CCN, and then create the NAT gateway route and the CVM under the Guangzhou VPC.
Step 5: Publishing the NAT Route to the CCN
Log in to the VPC - Route Table console and publish the created NAT gateway route to the CCN. For detailed operations, refer to the document Managing Routing Policies.
Note:
1. It does not support publishing the NAT routes of different VPCs to the CCN.
2. It only supports publishing the NAT routes of a single VPC to the CCN, and multiple NAT routes of that VPC can be published to the CCN.
Note:
1. When the NAT routes are published to the CCN, the system will automatically create a route table named system-auto-for-nat-ccn, for which the associated subnet is 0. The route table contains routes used in the return traffic of the public network, namely NAT gateway routes pointing to the CCN. Generally, users do not need to modify it.
2. A VPC will create only 1 route table named system-auto-for-nat-ccn. If already exists, it will not be created again. This route table will be automatically deleted when the last NAT route is withdrawn from the CCN or when the VPC is unbound from the CCN.
Step 6: Enabling a Route
When the NAT route is the default route
0.0.0.0, you must manually enable the route due to a conflict in the route's destination CIDR. Log in to the VPC - CCN console. For detailed operations, refer to Enabling a Route.Step 7: Verifying the Traffic
A successful ping on the CVM indicates that the public network can be accessed.
Deletion Process
Step 1: Withdrawing the Route
Step 2: Verifying the Route
1. Log in to the VPC - Route Table console and check whether the system-auto-for-nat-ccn route table has also been deleted.
2. Log in to the VPC - CCN console and check whether the route
0.0.0.0 in the CCN route table has also been deleted.
Yes
No
Was this page helpful?