Cloud Operational models - The Good and The Ugly

When Aviatrix conducts ACE trainings, we often have Site2Cloud labs in which IPsec tunnels are created to on-prem branch routers. Occasionally, to emulate a branch router, we use a Cisco Cloud Services Router (CSR) stood up in AWS.

When you're creating an IPsec tunnel using the Strongswan IPsec implementation, you need to specify a Remote Identifier, which is the WAN IP of the CSR.

However, the Cisco CSR does not act as a true branch router in that it is actually being NAT'd by an AWS IGW. For that purpose, when you are building an IPsec tunnel using IKEv1, you need to specify that the Remote Identifier of the IKE tunnel is actually the private IP of the CSR, not the public IP that the IGW gives it.

To find out the Private IP of the CSR, one way to find out is to log in to the AWS Console (assuming you have access). Another way is to SSH to the router and issue the IOS command show ip interface brief, such as this:

Then you would take the IP address specified by GigabitEthernet1, and use that as the Remote Identifier when configuring the Site2Cloud connection on the Aviatrix Controller.

It is a super ugly approach to a basic task.

This is what we at Aviatrix refer to as a Cloud naive approach. Despite the use of the word 'Cloud' in 'Cloud Services Router', the CSR doesn't even know it is in the Cloud.

This is exactly what Aviatrix CEO Steve Mullaney meant in his SiliconAngle theCUBE interview at AWS re:Invent 2021 when he said “Guess what, CSR doesn’t even know it’s in the Cloud. It’s looking for ports. The operational model is horrendous.”

What is an example of a proper operational model? Look no further than the Aviatrix Transit, which takes care of IPsec, ECMP, HA, route table creation, subnet creation, RFC1918 routes, 0/0 routes, and so much more from a single Terraform provider, in a repeatable fashion regardless of which cloud you're in. It's an architecture that's built with simplicity and with Operations teams in mind.