Aviatrix-Episode3: Connecting OnPrem Remote site to Aviatrix Cloud infrastructure via BGPoIPSEC (incl. BGP route approval)

 Today, we will simulate an "On Prem" Data Centre connected to our existing MultiCloud Network infrastructure. For this, we will use Aviatrix feature called Site2Cloud (aka S2C).

You might remember in the previous blogpost that it has been used to connect Aviatrix GWs to AWS Cloud WAN via IPSEC & GRE.

What is S2C?

Connectivity's

S2C allows your Aviatrix GWs (Spoke or Transit) to be connected to many different entities. This can be:

• On Prem DC or Branch
• BGPoIPSEC to secure connections over Internet or Private Lines. High Performance Encryption (HPE) is available by overcoming the bandwidth limitations of a single IPSEC tunnel (1.25 Gbps)
• BGPoGRE (AWS only on Private Lines (DX)) to extend Aviatrix overlay without IPSEC limitations

• 3rd party appliances like SDWAN with BGPoLAN
• Route exchange without any tunnelling protocol
• High Performance, widely compatible SDWAN integration
• Integrates with GCP NCC

• Cloud Native Constructs (seen with AWS Cloud WAN). As an example, it can be:
• BGPOIPSEC & BGPoGRE with AWS TGW / Cloud WAN
• BGPoIPSEC with Azure VWAN

BGP Route Approval

One cool feature with S2C is BGP Route Approval in the Aviatrix Transit GWs. It allows you to filter unwanted routes propagated by the remote connection over BGP. [for the small anecdote, I faced recently a customer having had a big outage because default route was propagated into its Public Cloud causing substantial damages]

The process is the following:

1. New routes from remote connection are propagated to Aviatrix Transit over BGP

2. The Aviatrix Transit Gateway reports these new routes to the Aviatrix Controller

3. The Aviatrix Controller notifies the Admin. via email

4. Admin. logs into the Aviatrix Controller to approve these new routes

5. If approved, the Aviatrix Controller programs the new routes to the Aviatrix Spoke Gateways.

Other benefit provided by S2C

Imagine you are in the Context of Merger & Acquisitions: you have acquired a new company with a Cloud Infrastructure and / or On Prem Data Centre with IP overlapping with your own Cloud Infrastructure. You want to keep the control over this, but what solutions do you have with Cloud Native? Aviatrix offers multiple solutions with Natting. 

NOTE: Natting scenarios will be discussed in later blog posts & are out of scope for this blog.

Architecture 

• A simulated On Prem DC connect to the Cloud via Cisco CSR1000V Virtual Router over Internet (S2C, BGPoIPSEC)

• The 2 Aviatrix Transit GWs in AWS connects this On Prem via 2 distinct IPSEC Tunnels (when HA is enabled, this is automatically configured)

• BGP Route Approval is enabled in the Aviatrix GWs located in AWS. We will only allow Loopback0.

• We will then exclude Loopback0 in the Transit peering to see that VM VNET1 is not reachable anymore.

Configuration

Configuration of S2C - Aviatrix Controller

• External Device for Cisco CSR Connection

• BGPoIPSEC

• Configure Aviatrix BGP ASN & Cisco CSR BGP ASN

• Select the Primary Aviatrix GW (bear in mind that if you are in HA mode, 2 IPSEC Tunnels (1 per Aviatrix GW) will be created)

• 'Learned CIDR approval is set to 'enabled' to activate BGP Route Approval

• Remote GW IP is the Public IP of Cisco CSR Router

• Pre Shared Key configured

Cisco CSR1000V Provisioning

1. Subscribe & Launch a new EC2

2. Launch EC2 Instance for Cisco Virtual Router

3. Allocate & Associate EIP to CSR Instance

4. You are now able to login into the CSR Instance

Download & Install BGP / IPSEC configuration from Aviatrix Controller

Only the following must be adapted according to your needs:

• IKE crypto_policy number

• IPSEC Tunnel Interfaces (*2)

• Source Interface of the Cisco CSR for IPSEC (Public IP)

Please see full configuration.

The 2 IPSEC tunnels (to Transit & Transit HA) go UP.

You are even notified by the Aviatrix Controller via email of the status change of your IPSEC tunnels to Cisco CSR!! (since Controller Version 6.8)

Let's create the 2 loopback interfaces depicted in the diagram.

As we enabled BGP Route Approval, we receive notifications from Aviatrix Controller that we need to approve or deny the new CIDRs propagated via BGP by the Cisco CSR to the Aviatrix Transit GWs.

I decide to approve only Loopback0 for the purpose of the tests. (don't forget to click on 'Update')

Visualization & testing

Route table of Azure Spoke Vnet1 GW in Copilot. Only 10.10.10/24 has been propagated as foreseen.

Ping from Lo0 & Lo1 CSR to VM VNET1. Only ping from Lo0 is successful as whished.

Now filter Lo0 on the Transit peering between AWS & Azure. (configuration must be symmetric on the 2 Transit otherwise it will be rejected)

PING NOK as foreseen

BOTTOM Line

• S2C is a very easy Aviatrix product to use to connect your Cloud to any kind of Remote site via different flavours (BGPoLAN for SDWAN, BGPoIPSEC to connect Cloud Native constructs or remote sites over Internet), BGPoGRE for remote private connections, etc..)

• High Performance Encrytion (IPSEC) can be enabled to allow you more bandwidth to your remote site

• Fancy mechanisms to overcome the Cloud Native limitations & relieve you from pain (NAT and BGP Route Approval)

• You can even download the configuration of your remote device for an easy integration!

Next episodes foreseen:

Episode4: Embedded L4 Stateful FWs on Aviatrix GWs

Episode5: All you need to know about Aviatrix FQDN Filtering - Design Patterns

Episode6: Aviatrix Copilot Tour (including Cyber Threat Protection with ThreatIQ/ThreatGuard)

Episode7: How to spin up a fully resilient multicloud environment in minutes with Terraform