Using a Third-Party Firewall to Scrub Traffic for VPCs Connected by VPC Peering Connections
Application Scenario
VPC allows you to configure and manage virtual networks. You can use security groups and network ACLs to control network access. You can also use third-party firewalls to ensure the security of cloud services.
This section describes how to use a firewall to scrub traffic across VPCs that are connected using VPC peering connections.
Architecture
In this example, services are deployed in VPC-A, VPC-B, and VPC-C, and the firewall is deployed in VPC-X. These VPCs communicate with each other through VPC peering connections. The traffic across VPC-A, VPC-B, and VPC-C must flow through the firewall in VPC-X. The default route table of VPC-X directs all inbound traffic to the firewall. After being scrubbed by the firewall, the traffic is sent to a service VPC based on the custom route table.
Figure 1 shows how ecs-A01 accesses ecs-C01. You can view the request and response traffic paths.
Resource Planning
In this example, you need to create VPCs, ECSs, and VPC peering connections. For details about required resources, see Table 1.
![](https://support.huaweicloud.com/intl/en-us/bestpractice-vpc/public_sys-resources/note_3.0-en-us.png)
The following resource planning details are only examples for your reference. You need to plan resources based on actual service requirements.
Resource |
Description |
---|---|
VPC |
Table 2 shows details about the required VPCs. In this example, there are four VPCs, including three VPCs where services are deployed and one VPC where the firewall is deployed. These VPCs are from the same region, and their subnet CIDR blocks do not overlap.
NOTICE:
The subnet CIDR blocks of the VPCs that need to communicate with each other through a VPC peering connection cannot overlap. Otherwise, the VPC peering connection does not take effect. For details, see Unsupported VPC Peering Configurations. |
ECS |
Table 3 shows details about the required ECSs. The four ECSs are in different VPCs. If the ECSs are in different security groups, add rules to the security groups to allow access to each other. |
VPC peering connection |
Table 4 shows details about the required VPC peering connections.
There are three VPC peering connections.
VPC peering connections are transitive. After routes are configured, VPC-A, VPC-B, and VPC-C can communicate with each other through VPC-X. |
VPC Name |
VPC CIDR Block |
Subnet Name |
Subnet CIDR Block |
Route Table |
Subnet Is Used to Deploy |
---|---|---|---|---|---|
VPC-A |
10.1.0.0/16 |
subnet-A01 |
10.1.0.0/24 |
Default route table |
Services |
VPC-B |
10.2.0.0/16 |
subnet-B01 |
10.2.0.0/24 |
Default route table |
Services |
VPC-C |
10.3.0.0/16 |
subnet-C01 |
10.3.0.0/24 |
Default route table |
Services |
VPC-X |
192.168.0.0/16 |
subnet-X01 |
192.168.0.0/24 |
Custom route table |
Firewall |
ECS Name |
VPC Name |
Subnet Name |
Private IP Address |
Image |
Security Group |
ECS Is Used to Deploy |
---|---|---|---|---|---|---|
ecs-A01 |
VPC-A |
subnet-A01 |
10.1.0.139 |
Public image: CentOS 8.2 64bit |
sg-demo: General-purpose web server |
Services |
ecs-B01 |
VPC-B |
subnet-B01 |
10.2.0.93 |
Services |
||
ecs-C01 |
VPC-C |
subnet-C01 |
10.3.0.220 |
Services |
||
ecs-X01 |
VPC-X |
subnet-X01 |
192.168.0.5 |
Firewall |
Route Configuration
You need to add routes to VPC route tables to allow communication between VPCs and scrub traffic through the firewall. For details, see Table 5.
![](https://support.huaweicloud.com/intl/en-us/bestpractice-vpc/public_sys-resources/note_3.0-en-us.png)
The following routes are only examples for your reference. You need to plan routes based on actual service requirements.
Route Table |
Description |
---|---|
Route tables of service VPCs |
Table 6 shows details about route tables of service VPCs. The default route tables of VPC-A, VPC-B, and VPC-C have routes with destinations set to other VPC subnets and with next hop set to VPC peering connection. |
Route tables of firewall VPC |
Table 7 shows details about route tables of the firewall VPC-X.
|
VPC Name |
Route Table |
Destination |
Next Hop Type |
Next Hop |
Route Type |
Route Function |
---|---|---|---|---|---|---|
VPC-A |
Default route table: rtb-vpc-A |
10.2.0.0/24 |
VPC peering connection |
peer-AX |
Custom |
|
10.3.0.0/24 |
VPC peering connection |
peer-AX |
Custom |
|
||
192.168.0.0/24 |
VPC peering connection |
peer-AX |
Custom |
|
||
VPC-B |
Default route table: rtb-vpc-B |
10.1.0.0/24 |
VPC peering connection |
peer-BX |
Custom |
|
10.3.0.0/24 |
VPC peering connection |
peer-BX |
Custom |
|
||
192.168.0.0/24 |
VPC peering connection |
peer-BX |
Custom |
|
||
VPC-C |
Default route table: rtb-vpc-C |
10.1.0.0/24 |
VPC peering connection |
peer-CX |
Custom |
|
10.2.0.0/24 |
VPC peering connection |
peer-CX |
Custom |
|
||
192.168.0.0/24 |
VPC peering connection |
peer-CX |
Custom |
|
VPC Name |
Route Table |
Destination |
Next Hop Type |
Next Hop |
Route Type |
Route Function |
---|---|---|---|---|---|---|
VPC-X |
Default route table: rtb-vpc-X |
0.0.0.0/0 |
Server |
ECS-X |
Custom |
If your firewall is deployed on multiple ECSs and these ECSs communicate with external networks through a virtual IP address, set the next hop of the route to the virtual IP address. |
Custom route table: rtb-vpc-custom-X |
10.1.0.0/24 |
VPC peering connection |
peer-AX |
Custom |
|
|
10.2.0.0/24 |
VPC peering connection |
peer-BX |
Custom |
|
||
10.3.0.0/24 |
VPC peering connection |
peer-CX |
Custom |
|
Notes and Constraints
- A VPC peering connection can only enable communication between VPCs in the same region.
- The subnet CIDR blocks of the VPCs that need to communicate with each other through a VPC peering connection cannot overlap. Otherwise, the VPC peering connection does not take effect. For details, see Unsupported VPC Peering Configurations.
- The subnet where the ECS deployed with a third-party firewall resides needs to be associated with a custom route table. Ensure that the region where your resources are located supports custom route tables.
If Route Tables is displayed in the left pane of the network console, custom route tables are supported.
Figure 2 Route Tables
Procedure
- Create four VPCs and their subnets in region A.
For details, see Creating a VPC.
For details about VPCs and their subnets, see Table 2.
- Create a custom route table in VPC-X and associate subnet-X01 with the custom route table.
- Create a custom route table in VPC-X.
For details, see Creating a Custom Route Table.
- Associate subnet-X01 with the custom route table created in 2.a.
After subnet-X01 is created, it is automatically associated with the default route table of VPC-X. You need to associate the custom route table created in 2.a to subnet-X01.
For details, see Changing the Route Table Associated with a Subnet.
- Create a custom route table in VPC-X.
- Create an ECS in each VPC.
For details, see Purchasing an ECS.
- Configure the NIC of ecs-X and install the third-party firewall on ecs-X.
- Disable source/destination check for the NIC of ecs-X.
- In the ECS list, click the name of the target ECS.
- On the Network Interfaces tab, click
to expand the details area and check whether Source/Destination Check is disabled.
If the information shown in Figure 3 is displayed, Source/Destination Check is disabled.
- Install a third-party firewall on ecs-X.
- Disable source/destination check for the NIC of ecs-X.
- (Optional) Configure a virtual IP address for ECSs.
You can create two ECSs in VPC-X and bind them to the same virtual IP address so that they can work in the active and standby mode. If the active ECS is faulty and cannot provide services, the virtual IP address will be dynamically switched to the standby ECS to continue providing services. Skip this step if the ECS where the firewall is deployed does not need to work in the active/standby mode.
- Assign a virtual IP address in the VPC-X subnet.
For details, see Assigning a Virtual IP Address.
- Bind the virtual IP address to the active and standby ECSs where the firewall is deployed.
For details, see Binding a Virtual IP Address to an EIP or ECS.
- Assign a virtual IP address in the VPC-X subnet.
- Create three VPC peering connections and configure routes.
- Create three VPC peering connections.
- If your VPCs are in the same account, see Creating a VPC Peering Connection with Another VPC in Your Account.
- If your VPCs are in different accounts, see Creating a VPC Peering Connection with a VPC in Another Account.
For details about VPC peering connections, see Table 4.
- In the default route tables of the three service VPCs, add routes with destination set to the other three VPCs and with next hop set to the VPC peering connection.
For details, see Adding a Custom Route.
In this example, add the routes planned in Table 6 to the route tables of VPC-A, VPC-B, and VPC-C.
- Add routes to the default and custom route tables of the firewall VPC.
For details, see Adding a Custom Route.
In this example, add the routes planned in Table 7 to the default and custom route tables of VPC-X.
- Create three VPC peering connections.
- Log in to the ECS and check whether the firewall takes effect.
Multiple methods are available for logging in to an ECS. For details, see Logging In to an ECS.
In this example, use VNC provided on the management console to log in to an ECS.
- Log in to ecs-A01 and verify the network connectivity between VPC-A and VPC-B.
ping Private IP address of ecs-B01
Example command:
ping 10.2.0.93
If information similar to the following is displayed, the two VPCs can communicate with each other.
[root@ecs-A01 ~]# ping 10.2.0.93 PING 10.2.0.93 (10.2.0.93) 56(84) bytes of data. 64 bytes from 10.2.0.93: icmp_seq=1 ttl=64 time=0.849 ms 64 bytes from 10.2.0.93: icmp_seq=2 ttl=64 time=0.455 ms 64 bytes from 10.2.0.93: icmp_seq=3 ttl=64 time=0.385 ms 64 bytes from 10.2.0.93: icmp_seq=4 ttl=64 time=0.372 ms ... --- 10.2.0.93 ping statistics ---
- Keep the network connectivity between VPC-A and VPC-B in 7.a and log in to ecs-X01 to verify whether the traffic from VPC-A to VPC-B flows through ecs-X01.
- On ecs-X01, check the traffic change on eth0.
Run the following command at least twice consecutively to check whether the values of RX packets and TX packets change:
ifconfig eth0
If the packets change, the traffic flows through ecs-X01 and is scrubbed by the firewall.[root@ecs-X01 ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::f816:3eff:feb6:a632 prefixlen 64 scopeid 0x20<link> ether fa:16:3e:b6:a6:32 txqueuelen 1000 (Ethernet) RX packets 726222 bytes 252738526 (241.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 672597 bytes 305616882 (291.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ecs-X01 ~]# ifconfig eth0 eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.5 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::f816:3eff:feb6:a632 prefixlen 64 scopeid 0x20<link> ether fa:16:3e:b6:a6:32 txqueuelen 1000 (Ethernet) RX packets 726260 bytes 252748508 (241.0 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 672633 bytes 305631756 (291.4 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
- Repeat 7.a to 7.c to check the communication between other VPCs.
- Log in to ecs-A01 and verify the network connectivity between VPC-A and VPC-B.
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot