Configuring Cloud Interconnect access to cloud networks behind NGFWs

In this tutorial, we will create a secure high-availability Yandex Cloud network infrastructure using a next-generation firewall (NGFW) to segment it into security zones. Each network segment will contain single-purpose resources isolated from others. For example, we will place public-facing services, e.g., frontend applications, in the DMZ segment and backend applications in the Application segment. Each segment will have its own cloud folder and a dedicated VPC cloud network. To connect these segments, we will use Next-Generation Firewall VMs deployed in two availability zones to ensure fault tolerance.

In Yandex Cloud tutorials, you can find the following NGFW-based implementations of a fault-tolerant network infrastructure:

• UserGate
• Check Point

To establish IP network connectivity between your on-premise resources and Yandex Cloud resources, you can use Yandex Cloud Interconnect.

In this tutorial, you will set up routing for your cloud network and configure a Cloud Interconnect private connection to enable network connectivity between your on-premise infrastructure and the segments hosted behind the NGFW.

You can see this solution in the diagram below.

Traffic routing from your on-premise infrastructure to the and VPC-hosted resourcesTraffic routing from your on-premise infrastructure to the dmz and app VPC-hosted resources

If the prerequisites are met and your cloud route tables and Cloud Interconnect are configured according to steps below:

• Your on-premise infrastructure traffic will arrive at the primary NGFW that will route it to the relevant VPC: dmz or app.
• If the primary NGFW fails, the route-switcher module will redirect the traffic arriving at the primary zone to the standby NGFW in the different availability zone.
• If the availability zone with the primary NGFW fails, the route-switcher module will redirect traffic to the standby NGFW that will further route it to the relevant VPC: dmz or app.

PrerequisitesPrerequisites

1. Use route-switcher to switch interconnect, dmz, and app VPC-directed traffic from the primary to the standby NGFW if the first one fails. You can read about route-switcher in the UserGate NGFW and Check Point NGFW tutorials.
2. Network prefixes in the route tables must not overlap your on-premises network prefixes.
3. Routes announced from the on-premise infrastructure through Cloud Interconnect must not overlap with the address spaces of the interconnect, dmz, or app VPC subnets.
4. Prefixes in the Cloud Interconnect private connection announcements, i.e., A.A.A.0/24, B.B.B.0/24, C.C.0.0/16, and D.D.0.0/16 in our example, must not overlap.
5. The NGFW must have security policies allowing access from the interconnect VPC to the dmz and app VPC, based on your organization’s security requirements.
6. Route tables for the dmz and app VPC subnets must include routes to your on-premise infrastructure networks. A common practice is to use the default route, 0.0.0.0/0. These routes must use the primary NGFW for Next hop.
7. The NGFW must have static routes to your on-premise infrastructure networks. For Next hop, these routes must use the gateway address, which is the first address in the interconnect VPC NGFW-hosting subnet, e.g., x.x.x.1 for the x.x.x.x.0/24 subnet.
8. We recommend you to plan your dmz and app VPC network address space the way you can use aggregated prefixes. In our example, it is C.C.0.0/16 and D.D.0.0/16. With aggregated prefixes, you will only need to configure interconnect VPC route tables and prefix announcements in private Cloud Interconnect connections once. You will not have to change them when adding new subnets to the dmz and app VPC.

Configuring VPC route tablesConfiguring interconnect VPC route tables

Configure route tables in the interconnect VPC according to the tables below and apply them to the primary and standby NGFW-hosting subnets.

Create a route table containing more specific routes (with a network prefix /17) to the dmz and app VPC subnets and apply it to the primary NGFW-hosting subnet, i.e., A.A.A.0/24 in zone A. Remember to add prefixes from that table to the announcement settings for private connections of the primary NGFW availability zone.

Create a route table containing less specific routes (with a network prefix /16) to the dmz and app VPC subnets and apply it to the standby NGFW-hosting subnet, i.e., B.B.B.0/24 in zone B. Remember to add prefixes from that table to the announcement settings for private connections of the standby NGFW availability zone.

These settings ensure that traffic to the dmz and app VPC subnets is routed to the primary NGFW. If the primary NGFW fails, the route-switcher will redirect traffic to the standby NGFW.

By using more specific or less specific route table prefixes, you can configure the Cloud Interconnect private connection announcements so that your on-premise infrastructure traffic bound for the dmz and app VPC subnets goes to the primary NGFW availability zone and, if that one fails, it is redirected to the standby NGFW availability zone.

Creating private Cloud Interconnect connectionsCreating private Cloud Interconnect connections

You can find the Cloud Interconnect deployment options in the documentation. For a fault-tolerant connection to the service, we recommend setting up multiple trunks, one per point of presence.

Follow this guide to set up a private connection depending on how you connect to Cloud Interconnect.

When submitting a ticket to Yandex Cloud support, specify the following for each private connection in your subnet announcements for availability zones:

1. For the primary NGFW availability zone:
   • Prefixes from the route table applied to the interconnect VPC primary NGFW-hosting subnet. In our example, these are more specific /17 prefixes for the ru-central1-a zone. These announcements will ensure that your on-premise traffic bound for the dmz and app VPC subnets will go to the primary NGFW availability zone.
   • Prefix of the interconnect VPC primary NGFW-hosting subnet, along with other interconnect VPC subnet prefixes in the same zone that you need to announce into your on-premise infrastructure.
2. For the standby NGFW availability zone:
   • Prefixes from the route table applied to the interconnect VPC standby NGFW-hosting subnet. In our example, these are less specific /16 prefixes for the ru-central1-b zone. These announcements will ensure that your on-premise traffic bound for the dmz and app VPC subnets will go to the standby NGFW availability zone if the primary zone fails.
   • Prefix of the interconnect VPC standby NGFW-hosting subnet, along with other interconnect VPC subnet prefixes in the same zone that you need to announce into your on-premise infrastructure.

For our tutorial example, specify the following details under vpc:

vpc: 
  vpc_net_id: <VPC_interconnect_ID> 
    vpc_subnets:
      ru-central1-a: [A.A.A.0/24, C.C.0.0/17, C.C.128.0/17, D.D.0.0/17, D.D.128.0/17]
      ru-central1-b: [B.B.B.0/24, C.C.0.0/16, D.D.0.0/16]