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 resources in your infrastructure and cloud resources in Yandex Cloud, 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 segments hosted behind the NGFW.

You can see the solution architecture in the diagram below.

Traffic routing from your on-premise infrastructure to the VPC-hosted and resourcesTraffic routing from your on-premise infrastructure to the VPC-hosted dmz and app 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 a 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 with your on-premises network prefixes.
3. Routes announced from your on-premise infrastructure through Cloud Interconnect must not overlap with the address spaces of the interconnect, dmz, or app VPC subnets.
4. IP prefixes added to the virtual router, 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. Configure security policies on the NGFW to allow access from VPC interconnect to VPC dmz and app as per your organization's security requirements.
6. Add routes to the networks used in your on-premises infrastructure to the routing tables for the dmz and app VPC subnets. A common practice is to use the default route, 0.0.0.0/0. For these routes, specify the IP address of the primary NGFW in the appropriate VPC dmz or app as Next hop.
7. Configure static routes on the NGFW to the networks used in your infrastructure. For these routes, specify the gateway address (the first address in the subnet range, e.g., x.x.x.1 for the x.x.x.0/24 subnet) from the cloud subnet of the NGFW interface in VPC interconnect as Next hop.
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 VPC interconnect route tables and prefix announcements in the virtual router once. When adding new subnets to VPC dmz and app, you will not need to change these settings.

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 of the virtual router for the primary NGFW's 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 of the virtual router for the standby NGFW's 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 or less specific route table prefixes, you can configure the virtual router announcements so that your on-premise infrastructure traffic bound for the VPC dmz and app subnets goes to the primary NGFW's availability zone and, if that one fails, is redirected to the standby NGFW's availability zone.

Configure Cloud Interconnect and a virtual routerConfigure Cloud Interconnect and a virtual router

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

1. Create trunks and organize their physical connection. If trunks have already been created, use the existing ones.

2. In each trunk, create a private connection.

3. Create a virtual router or select an existing one.

4. Add private connections to your virtual router.

5. Add an interconnect network to your virtual router and specify the following IP prefixes:

   Availability zone	IP prefixes
   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

/17 prefixes route traffic to the zone with the primary NGFW. If this zone becomes unavailable, more specific prefixes stop being announced and traffic is routed through /16 prefixes to the zone with the standby NGFW.

Check the status of BGP sessions for private connections through monitoring.

If you are creating new subnets on an already announced aggregate prefix, you do not need to change the virtual router settings. To announce a prefix outside of the configured aggregate, update the IP prefixes on your own.