VPC Firewall supports achieving traffic steering through two access modes: multi-route table and policy-based routing via CCN. In manual access mode, after the Firewall Toggle is enabled, the traffic of the CCN instance will not be automatically protected. You need to go to the console of that CCN instance and perform manual configuration based on the selected mode.
Multi-Route Table Access Mode
This article will take a cross-regional business protection scenario as an example to demonstrate how to connect and divert traffic from service VPCs in different regions to a firewall VPC located in the central region for centralized protection. The specific network architecture is as follows:
Service VPC-A: deployed in the Beijing region, carries business traffic for the Beijing area.
Service VPC-B: deployed in the Chongqing region, carries business traffic for the Chongqing area.
Firewall VPC-BJFW: deployed in the Beijing region, serves as a central protection node for receiving and inspecting traffic from Service VPCs.
Step 1: Select Manual Access Mode
Enable the Firewall Toggle and select manual access mode. See Firewall Toggle. Step 2: Configure Traffic Steering Policy
1. Select Multi-route table for manual access mode.
2. Select the creation method for the traffic-steering VPC:
Not Now: You must create a traffic-steering VPC in at least one region. Select Automatic assignment or Custom.
Automatic assignment: CFW will automatically probe for idle 26-segment VPC CIDR blocks for firewall traffic steering.
Custom: You can define the VPC CIDR block for firewall usage. Note that it must be a /26 CIDR block (such as 10.0.0.0/26).
3. Click Create. The system will create an access VPC in the region where the VPC associated with the current CCN instance is located. This process is expected to take about 30 seconds; please wait patiently.
Step 3: Confirm Whether the Firewall Traffic Steering VPC Has Been Successfully Created
1. Log in to VPC console, in the left sidebar, click CCN. 2. In the CCN instance list, click the target instance's ID/Name.
3. In the Associated To tab, check whether there is a VPC instance named Dedicated firewall VPC Do not delete or modify with its status as Connected, indicating that the traffic diversion VPC required by the firewall has been successfully created.
Step 4: Configure Traffic Diversion Routes
The purpose of this operation is to divert traffic from the business CCN instances that require protection through the firewall gateway to Cloud Firewall (CFW).
1. Navigate to the console of the CCN instance selected when the VPC Border Firewall is enabled, and view the details of the CCN instance associated with the multi-route table mode.
2. Confirm that the VPC for firewall traffic diversion and relevant routing tables have been created. If not, wait for the instance creation to complete or submit a ticket to contact us for assistance. 3. View the default route table page to identify the business VPC and firewall traffic diversion VPC that need to be connected.
4. Navigate to the VPC > Route Tables > Routing Tables page, choose the firewall traffic diversion VPC that needs to be connected. You will see route tables including "Firewall_VPC_Dedicated_Route_Table_Do_Not_Delete_or_Modify" and "default". Choose the "default" route table to edit route policies. 5. Click Add routing policy to divert traffic from the business VPC to the firewall by setting the next hop.
Enter the CIDR of the business VPC for the destination. Select Gateway Load Balancer Endpoint for the next hop type, choose Firewall Gateway ID for the next hop, and remarks can be filled in optionally.
Note:
If prompted that "the specified CIDR results in ECMP," you need to temporarily disable the relevant service routes in the default route table first.
6. Publish the new routes to CCN. For details, see Manage Route Policies. After publishing, the specified route policies can be viewed in the default route table of the corresponding CCN. Note:
Due to conflicts between the new route policy and the original one, the original route entry will become invalid and can be ignored.
Step 5: Create an Inter-VPC Access Route Table and Bind Instances
The purpose of the current operation is to establish connectivity between the firewall network and the user's business network, enabling mutual network access.
1. On the CCN page, create route tables separately for each business VPC that diverts traffic to the firewall. 2. Adjust their route acceptance policies in the dedicated route table of each VPC:
a. First, add the VPC instance associated with the route table itself and all VPC instances that do not pass through the firewall and require direct communication to the route table.
b. After completing the previous step, click Add Network Instance again to add the VPC instance dedicated to firewall traffic steering (such as VPC-BJFW) to the same route table.
3. Check whether the route entries in each VPC's dedicated route table are as expected.
4. In the operation column of each VPC's dedicated route table, click Bind Network Instance to bind the route table to its corresponding VPC instance. After this operation is completed, network traffic will be successfully diverted to the firewall.
Note:
Be sure to verify that the routes are correct before binding the route table, as the binding will take effect immediately.
Step 6: Verify Whether the VPC Is Connected Successfully
1. Refer to Log Auditing to check whether there are traffic logs. 2. Refer to Log Auditing to check whether Intrusion Defense is functioning properly. 3. Configure inter-VPC rules and check whether they are hit normally.
The firewall is now functioning properly. If your network architecture is complex or involves dedicated line scenarios, submit a ticket to consult detailed solutions for routing configuration; feel free to submit a ticket if you have further questions. Disconnecting CCN Instances From CFW (Multi-Route Table)
Note:
Be sure to disable the corresponding VPC Firewall Toggle only after confirming that the CCN instance has been disconnected from CFW; otherwise, it will cause network interruption.
1. Go to the console of the CCN instance where you need to disable the VPC Firewall, and view the details of the CCN instance associated with protected objects in multi-route table mode.
2. Except for the firewall-dedicated VPC, bind all network instances to the routing tables previously used before they are connected to CFW.
2.1 Select the routing table used before you connect to CFW, usually the _default_rtb table.
2.2 Select all instances except those dedicated to the firewall.
2.3 Confirm routing and click Complete.
3. After it is confirmed that the network is functioning properly, disable the Firewall Toggle corresponding to the current CCN instance in the CFW console.
Policy-based Routing Access Mode
This article uses three VPCs located in different regions as an example to demonstrate how to achieve cross-region full mesh communication between VPCs through CCN and steer inter-instance traffic to CFW. The specific plan is as follows:
VPC-A: deployed in the Frankfurt region, network segment is XX.A.0.0/XX.
VPC-B: deployed in the Frankfurt region, network segment is XX.B.0.0/XX.
VPC-C: deployed in the Seoul region, network segment is XX.C.0.0/XX.
Note:
The policy routing access method in manual access mode is unavailable by default. If you want to experience this feature, submit a ticket to CFW. Before configuration, please ensure that your CCN instances support the policy routing feature. If the policy routing feature is unavailable, submit a ticket to CCN to apply for activation before you can use it. Step 1: Select Manual Access Mode
Enable the Firewall Toggle and select manual access mode. See Firewall Toggle. Step 2: Configure Traffic Steering Policy
1. Manual access mode selects policy routing.
2. Select the creation method for the traffic-steering VPC:
Not Now: You must create a traffic-steering VPC in at least one region. Select Automatic assignment or Custom.
Automatic assignment: CFW will automatically probe for idle 26-segment VPC CIDR blocks for firewall traffic steering.
Custom: You can define the VPC CIDR block for firewall usage. Note that it must be a /26 CIDR block (such as 10.0.0.0/26).
3. The system will create an access VPC in the region where the private network associated with the current CCN instance is located. The process will take approximately 30 seconds. Please wait.
Step 3: Confirm Whether the Firewall Traffic Steering VPC Has Been Successfully Created
1. Log in to VPC console, in the left sidebar, click CCN. 2. In the CCN instance list, click the target instance's ID/Name.
3. In the Associated Instances tab, check whether there are two VPC instances named Firewall-dedicated VPC_Do Not Modify or Delete, one located in the Frankfurt region and the other in the Seoul region, with their status as Connected. This indicates that the traffic diversion VPCs required by the firewall have been successfully created.
Step 4: Enable Intra-City Traffic Steering
To protect traffic between VPCs within the same region, you must submit a ticket to CCN to apply for intra-city traffic steering of VPC instances. Otherwise, this traffic will not pass through the firewall. Note:
During the enabling process, interruption of PaaS service sessions in the corresponding VPC may occur. This requires implementing an automatic reconnection mechanism for long-lived connections at the application layer to ensure prompt service recovery.
Step 5: Create Next Hop to the Firewall
1. On the CCN details page, choose Policy-based Routing > Next hop, and click Add.
2. Based on the regions where you created traffic diversion VPCs in Step 2, create next hops in the corresponding regions respectively. Configuration example (taking the Frankfurt region as an example): |
Region | Select Frankfurt. |
Name | Enter a recognizable name, such as Frankfurt_Firewall_Next_Hop. |
Next-Hop Instance Type | Select Virtual Private Cloud. |
Next-Hop Instance ID | Select the Dedicated firewall VPC Do not delete or modify in the corresponding region. |
Next Hop Access Resource Type | Select GWLB endpoint. |
Next Hop Access Resource ID | Select the corresponding Endpoint ID for the traffic redirection VPC (name usually contains cfw-Cloud Firewall Drainage Use Terminal). |
Description | Enter the next hop description |
3. After confirming, click OK.
4. Repeat this step to configure a next hop for each region where a traffic redirection VPC has been created.
5. Taking the scenario described in this article as an example, next hops will be created in the Frankfurt and Seoul regions respectively, as shown below:
Step 6: Create Policy-Based Routing Matching Rules
This step routes traffic between specific VPCs to the next hop (that is, the firewall) created in Step 3. 1. On the CCN instance details page, choose Policy-based Routing > Matching Rules, and click Add.
2. Create bidirectional rules for each pair of VPC CIDR blocks requiring mutual access based on your protection requirements. Take protecting traffic between VPC-A (XX.A.0.0/XX) and VPC-B (XX.B.0.0/XX) in Frankfurt as an example:
Rule 1 (VPC-A to VPC-B)
|
Priority | 1 (The smaller the number, the higher the priority). |
Source Instance Type | Virtual Private Cloud (VPC) |
Source Instance ID | VPC-A |
Source IP Range | XX.A.0.0/XX |
Destination IP range | XX.B.0.0/XX |
Next Hop ID | Select the next hop in the Frankfurt region. |
Rule 2 (VPC-B to VPC-A)
|
Priority | 2 |
Source Instance Type | Virtual Private Cloud (VPC) |
Source Instance ID | VPC-B |
Source IP Range | XX.B.0.0/XX |
Destination IP range | XX.A.0.0/XX |
Next Hop ID | Select the next hop in the same Frankfurt region. |
Note:
Cross-region traffic steering: If two VPCs are in different regions, the next hop for their traffic can be any firewall next hop in the source or destination VPC's region, but the traffic rules in both directions must point to the same next hop.
Same-region traffic steering:
If two VPCs are in the same region, the next hop for their traffic must be the firewall next hop in that region.
If the rules involve traffic between VPCs in the same region, you must submit a ticket to CCN to apply for intra-city traffic steering for the VPC instances. Otherwise, this traffic will bypass the firewall. The activation process may cause session interruptions for PaaS services in the corresponding VPC. Applications must rely on automatic reconnection mechanisms for long-lived connections at the application layer to ensure rapid service recovery. 3. After confirming, click OK.
4. Repeat this step to create two rules (inbound and outbound) in the same way for all inter-VPC traffic pairs that require protection.
5. Taking this scenario as an example, this example has 3 instances, each accessing one network segment, resulting in a total of 6 rules, as follows:
Step 7: Verify Whether the VPC Connection Is Successful
1. Refer to Log Auditing to check whether there are traffic logs. 2. Refer to Log Auditing to check whether Intrusion Defense is functioning properly. 3. Configure inter-VPC rules and check whether they are hit normally.
The firewall is now functioning properly. If your network architecture is complex or involves dedicated line scenarios, submit a ticket to consult detailed solutions for routing configuration; feel free to submit a ticket if you have further questions. CCN Instance Disconnect From CFW (Policy-based Routing)
Note:
Be sure to disable the corresponding VPC Firewall Toggle only after confirming that the CCN instance has been disconnected from CFW; otherwise, it will cause network interruption.
1. Delete all policy-based routing matching rules created for firewall traffic steering in Step 4. 2. Delete all policy-based routing next hops created for firewall traffic steering in Step 3. 3. Return to the CFW console, in the Firewall Toggle > VPC Boundary page, disable the firewall toggle for this CCN instance. The system will automatically clean up the created traffic steering VPCs and endpoints.