Configuring Cloud Interconnect access to cloud networks behind NGFWs

In Yandex Cloud, you can deploy a secure high-availability network infrastructure based on the Next-Generation Firewall (NGFW) technology, i.e. segmented into security zones. Each network segment (hereinafter, simply segment) contains single-purpose resources, isolated from other resources. For example, the DMZ segment is where public-facing services (such as frontend apps) reside, whereas the application segment hosts backend apps. Each segment in a cloud has its own folder and a dedicated VPC cloud network. Segments connect to each other via Next-Generation Firewall VM instances deployed in two availability zones to ensure fault tolerance.

Yandex Cloud tutorials discuss the following NGFW-based fault-tolerant network infrastructure implementation scenarios:

• UserGate
• Check Point

To set up IP network connectivity between resources in the customer's on-premise infrastructure and cloud resources in Yandex Cloud, use Yandex Cloud Interconnect.

This document covers the cloud network routing settings and Cloud Interconnect private connection settings to enable network connectivity between the customer's infrastructure and segments behind the NGFW.

Description of traffic routing from the customer's infrastructure to resources in the and VPCDescription of traffic routing from the customer's infrastructure to resources in the dmz and app VPC

If the prerequisites are met and your cloud route tables and Cloud Interconnect are set up as shown below:

• Traffic from the customer's infrastructure will be routed to the primary NGFW zone, and from there to the relevant VPC: dmz or app.
• If the primary NGFW fails, traffic will still be routed to the primary NGFW zone, and from there to the standby NGFW in the neighboring zone (provided that the route-switcher module is on).
• If the primary NGFW zone fails, traffic will be routed to the standby NGFW zone (provided the route-switcher module is on), and from there to the relevant VPC: dmz or app.

PrerequisitesPrerequisites

1. Employ the route-switcher module to switch traffic in the interconnect, dmz, and app VPC to the standby NGFW if the primary one fails. route-switcher is featured in UserGate NGFW or Check Point NGFW-based tutorials.
2. The configured route tables must not have any overlapping prefixes with networks used in the customer's on-premise infrastructure.
3. Routes announced from the customer's on-premise infrastructure through Cloud Interconnect must not overlap with the address spaces of the interconnect, dmz, and app VPC subnets.
4. Prefixes in the Cloud Interconnect private connection announcements (in the example, they are A.A.A.0/24, B.B.B.0/24, C.C.0.0/16, and D.D.0.0/16) must not overlap.
5. NGFW must have security policies in place to allow access from the interconnect VPC to the dmz and app VPC, subject to the customer's information security service requirements.
6. Route tables for subnets in the dmz and app VPC must contain routes to the networks used in the customer's on-premise infrastructure. The default route, 0.0.0.0/0, is normally used. For Next hop, these routes must use the IP address of the primary NGFW in the corresponding VPC: dmz or app.
7. The NGFW must have static routes configured to networks used in the customer's on-premise infrastructure. For Next hop, thee routes must use the gateway address (the first address in the subnet range, e.g., x.x.x.1 for the x.x.x.x.0/24 subnet) from the cloud subnet of the NGFW interface in the interconnect VPC.
8. We recommended that you plan your address plans in the dmz and app VPC so that aggregated prefixes (aggregates) can be used. Aggregates (in the example, these are С.С.0.0/16 and D.D.0.0/16) allow you to configure route tables in the interconnect VPC and prefix announcements in private Cloud Interconnect connections once and for all. You will no longer have to edit route tables in the interconnect VPC when adding new subnets to the dmz and appVPC, nor open support tickets to have announcements added to Cloud Interconnect.

Configure route tables in the interconnect VPCConfigure route tables in the interconnect VPC

Configure route tables in the interconnect VPC and apply them to the subnets hosting the network interfaces of the primary and standby NGFWs, according to the tables below.

To the subnet in the primary NGFW zone (A.A.A.0/24 in zone A), apply a route table containing more specific routes (those with the /17 prefixes in the example) to the subnets in the dmz and app VPC. Remember to add prefixes from that table to the announcement settings for private connections of the primary NGFW availability zone.

To the subnet in the standby NGFW zone (B.B.B.0/24 in zone B), apply a route table containing less specific routes (those with the /16 prefixes in the example) to the subnets in the dmz and app VPC. Remember to add prefixes from that table to the announcement settings for private connections of the standby NGFW availability zone.

The above settings ensure that traffic to subnets in the dmz and app VPC is routed to the primary NGFW. Provided that the route-switcher module is on, traffic will be routed to the standby NGFW should the primary one fail.

By using more specific or less specific route tables prefixes, you can configure the Cloud Interconnect private connection announcements so that the customer's infrastructure traffic bound for the dmz and app VPC subnets first goes to the zone with the primary NGFW and, if that one fails, is redirected to the zone with the standby NGFW.

Create private Cloud Interconnect connectionsCreate private Cloud Interconnect connections

Read about Cloud Interconnect deployment options in the documentation. For a fault tolerant connection to the service, several trunks are recommended – one per point of presence.

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

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

1. For the availability zone hosting the primary NGFW:
   • Prefixes from the route table applied to the primary NGFW subnet in the interconnect VPC. In the example for the ru-central1-a zone, these are the more specific prefixes, i.e., /17. Thanks to these announcements, the customer's infrastructure traffic bound for the dmz and app VPC subnets will be routed to the zone with the primary NGFW.
   • Subnet prefix for the primary NGFW network interface in the interconnect VPC and other subnet prefixes from the interconnect VPC in this zone that you need to announce into the customer's on-premise infrastructure.
2. For the availability zone hosting the standby NGFW:
   • Prefixes from the route table applied to the standby NGFW subnet in the interconnect VPC. In the example for the ru-central1-b zone, these are the less specific prefixes, i.e., /16. Thanks to these announcements, if the zone with the primary NGFW fails, the customer's infrastructure traffic bound for the dmz and app VPC subnets will be routed to the zone with the standby NGFW.
   • Subnet prefix for the standby NGFW network interface in the interconnect VPC and other subnet prefixes from the interconnect VPC in this zone that you need to announce into the customer's on-premise infrastructure.

For the example outlined in this document, specify the following details under vpc:

vpc: 
  vpc_net_id: <`interconnect` VPC 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]