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.

Figure 1 Networking planning when a third-party firewall is used for scrubbing traffic across VPCs

Resource Planning

In this example, you need to create VPCs, ECSs, and VPC peering connections. For details about required resources, see Table 1.

The following resource planning details are only examples for your reference. You need to plan resources based on actual service requirements.

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.

The following routes are only examples for your reference. You need to plan routes based on actual service requirements.

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

1. 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.

2. Create a custom route table in VPC-X and associate subnet-X01 with the custom route table.
   1. Create a custom route table in VPC-X.

      For details, see Creating a Custom Route Table.

   2. 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.

3. Create an ECS in each VPC.

   For details, see Purchasing a Custom ECS.

4. Configure the NIC of ecs-X and install the third-party firewall on ecs-X.
   1. Disable source/destination check for the NIC of ecs-X.
      1. In the ECS list, click the name of the target ECS.

         The ECS details page is displayed.

      2. 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.

         Figure 3 Disabling Source/Destination Check
         
   2. Install a third-party firewall on ecs-X.

5. (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.

   1. Assign a virtual IP address in the VPC-X subnet.

      For details, see Assigning a Virtual IP Address.

   2. 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.

6. Create three VPC peering connections and configure routes.
   1. 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.

   2. 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.

   3. 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.

7. Log in to the ECS and check whether the firewall takes effect.

   For details, see How Do I Log In to My ECS?.

   In this example, use VNC provided on the management console to log in to an ECS.

   1. 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 ---

   2. 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.
   3. 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

   4. Repeat 7.a to 7.c to check the communication between other VPCs.