Route on-premise internet traffic through AWS

Introduction

As companies of all sizes move into public cloud, a key question is often around internet access. Primarily for the servers and infrastructure within AWS, however as they begin to have less equipment on-premise and look to either make their datacenter/physical server footprint as small as possible, or close on-premise datacenters entirely they are often left with a key question. What can I do about the firewalls serving my on-premise infrastructure? Often these firewalls are the remaining infrastructure in a datacenter which not only keeps you tied to the datacenters, but also tied to all of the costs associated.

Other issues with maintaining physical hardware for these firewalls that will serve as your IPS, WAF, Webfiltering or other firewall services in an expanding company, are the same issue you’re probably moving your other services into cloud for:

  • Scalability, do you buy/provision a physical equipment for the size of your company now, or overspec to meet possible growth in the future?
  • Maintaining the hardware to run the equipment
  • Additional connection links for this datacenter endpoint
  • Additional hardware in the location just to support the services

Often when looking at companies cloud and on-premise infrastructure, I often see that people either run the following scenarios when it comes to internet breakouts:

Option 1: Internet for On-Premise and Private AWS subnets is routed through a physical or virtual firewall located at an on-premise or datacenter location providing a single egress and point to manage. With some public facing services being given internet access from an IGW directly (each server has a public EIP), which can often leave these servers vulnerable to attack.

Routing AWS and on-premise internet traffic through on-premise firewall
Routing AWS and on-premise internet traffic through on-premise firewall

Option 2: Internet for On-Premise is routed out through an on-premise or datacenter firewall. Internet traffic for AWS is routed through NAT instances giving little or no protection or scanning on egress traffic, or NAT’d services. Again, some public facing services being given internet access from an IGW directly (each server has a public EIP). This gives multiple points of egress onto the internet. When it comes to AWS workspaces, this can cause problems when looking to complete tasks such as web filtering.

Routing AWS internet through NAT and IGW, and on-premise through on-premise firewall
Routing AWS internet through NAT and IGW, and on-premise through on-premise firewall

The key point for both above common scenarios is that the on-premise firewall remains the main egress point to the internet for on premise.

The Problem

What if we want to migrate our main point of egress into AWS so that we can scale our firewall to deal with the load of IPS, WAF, Web-filtering etc; as our company expands? In reality completing this task the other way (ie; routing AWS servers to use on-premise firewalls) is fairly straight forward and easily achieved as we control on-premise devices and control what routes we advertise INTO AWS.

However, getting AWS to tell our on-premise network to use it as the default route regardless if we are using a Static or Dynamic VPN or even direct connect (DX) with BGP, it a much grander achievement. Even if you were to try simply getting your on-premise networks to route 0.0.0.0/0 to your AWS connection (VPN or DX) it simply wont work (trust me… I’ve tried it 😊). You may wonder why this is, when you clearly have your main VPC route table pointing 0.0.0.0/0 to an EC2 instance. The reason is that the route tables you have in AWS are associated to the subnets and the ENI’s that gets placed within those subnets, it has no effect on the VPG/VGW as for one, it wouldn’t know which route table to use. The only traffic that the VPG will understand and accept are routes/networks it learns about from:

  • BGP Peers (VPN or DX)
  • VPC CIDR Blocks its attached too as it learns routes to the VPC it’s attached too
  • Routes to subnets at the other end of a Static VPN (defined in the AWS console)

If traffic reaches a VPG and is for a network not known to it from any of the above methods, it will be dropped. This means that forcing traffic destined to public IP addresses will get blocked if the VPG hasn’t been told what to do with that traffic.

Traffic to unknown destination (internet) gets dropped by VPG
Traffic to unknown destination (internet) gets dropped by VPG

As mentioned earlier, we can advertise the 0.0.0.0/0 route FROM on-premise which would direct internet traffic to on-premise, but this is the opposite to what we want to achieve.

The Solution

Overview

So how do we achieve having all our on-premise networks internet traffic scanned by a Cloud Firewall located within AWS if we can’t manually control the VPG routing? The answer is… get clever with route advertisements.

One method could be to look into moving or implementing an AWS Transit Gateway architecture as the transit gateway service allows for very granular control over routing domains and advertisements to different VPC’s or attachments (DX or VPN). However, unless you are building and designing from scratch, this can be a large overhaul to your infrastructure and may affect more systems than your willing to at this point in time. I will document more around transit gateway in another article, for now I am going to focus on method 2, which integrates into your current environment.

The second method is to look to artificially manipulate the VPG’s routing and inject a default route, 0.0.0.0/0 via our cloud firewalls, (as we can with coming from on-premise) into it. But how can we do this as we don’t have a method of BGP to the VPG directly? Simple.. we use a method we know works and flip it around!

Solution Infrastructure

The main point to overcome is getting a route into the VPG that points 0.0.0.0/0 to our firewalls within AWS so that it knows where to direct the traffic and wont simply drop it.

We know we can influence the VPG and tell it about routes, including 0.0.0.0/0, simply by using dynamic VPN’s. We know that routes the VPG learns from these VPN’s will then be propagated to route tables in AWS (that have propagation enabled) and to other dynamic VPN and DX connections. The VPG will route traffic for the internet to the connection that is advertising 0.0.0.0/0.

So in order to get the VPG to direct internet traffic to our AWS firewalls, we need to create a Dynamic VPN from the Cloud Firewalls to our VPG and make sure that the firewalls dynamic VPN injects 0.0.0.0/0 into the VPG. This will cause the following routing scenario:

Using cloud firewall and BGP VPN to inject a default route into VPG and on-premise
Using cloud firewall and BGP VPN to inject a default route into VPG and on-premise

Your On-Premise Infrastructure

If you have multiple offices and branches, you may have a MPLS and a Direct Connect connection into your AWS environment. Your infrastructure may look like the following:

AWS with MPLS and DX (Direct Connect)
AWS with MPLS and DX (Direct Connect)

If you don’t have a direct connect and you are using a VPN to your AWS environment from a datacenter and are not looking to move to Direct Connect or are using a firewall as a backup VPN to AWS, you may still need a firewall device for the VPN connection but the performance requirement can be drastically reduced even when scaling your company by moving the heavy workload of filtering, scanning, IPS etc to your AWS firewalls. Meaning you could expand the lifespan of your on-premise firewalls until you look to replace. Providing they can support the throughput on the VPN’s you require, this is the only service they will need to perform. This may help you in a migration strategy, or even simply be a backup to direct connect.

AWS with MPLS and VPN from Datacenter firewall
AWS with MPLS and VPN from Datacenter firewall

If you have a single office or multiple offices without an MPLS, you will most likely have a firewall at each location with VPN’s to AWS or to each other with a single VPN to AWS, there are many ways this could be configured, but the principals are the same. If you currently have VPN’s interconnecting sites and then a single VPN to AWS, you may want to look at my up-coming article on using a Cloud hub architecture to make your infrastructure simpler to manage and maintain. Your infrastructure may look like the following:

AWS with VPN to multiple sites
AWS with VPN to multiple sites

Your AWS Infrastructure

Due to the nature of Public Cloud, this can obviously come in all shapes and sizes, with allot of work and design being down the preference of the architect, or business requirements and needs, to name a few:

  • Single VPC
  • Multiple VPC’s independent
  • Transit VPC architecture to link VPC’s and route between

For this, solution we are going to look at using your current VPC for the firewalls, however if you are looking to move into a Transit Gateway solution later down the line, you may want to start now, and build the firewalls in another VPC and link it back to the firewalls in a similar method until you make the move.

Note: It is always recommended to build firewalls in a HA method to allow for failover of AZ, however for this article I am focusing on the method of getting internet traffic to route externally. This can be expanded on by yourselves, or I will be looking to write up on firewall HA in this method in follow-up article, but for now… lets focus on the primary concept.

Example POC

Starting Infrastructure:

Let’s have a look at implementing the above solution and checking that the routing scenario suggested above works and that the default route will be advertised to all attached links, and also that the VPG does route traffic to our Cloud firewall. We will check that our client computers public IP is showing he EIP of the firewall.

Our example infrastructure

Our Starting On-Premise and AWS Environment
Our Starting On-Premise and AWS Environment

In our AWS environment, we have our Cloud Firewalls at the edge of our AWS infrastructure within the public subnets. The public subnets use their default route as the IGW. Private subnets within AWS use the ENI of the firewall as their default route. This is a similar setup if you were using NAT instances within your environment.

For our on-premise network, we have:

  • A Cisco ASA for our firewall
  • Networking switch.
  • Linux client connected to the switch
On-Premise lab
On-Premise lab

Our switch and ASA share routes between each-other via OSPF. We also have a dynamic VPN from our Cisco ASA to our AWS environment. This VPN to the AWS environment terminates on the VPC’s VPG (Virtual Private Gateway), this way it will simulate an existing environment being either a VPN or Direct Connect which would terminate here too.

Our ASA redistributes routes learned via BGP from the VPN into OSPF. It also distributes routes from OSPF into the BGP VPN for AWS to learn our on-premise subnets (route propagation is enabled on our private route tables).

To ensure that the test is accurate, the Cisco ASA has no default route, the only external routes it has are to the public endpoints AWS have provisioned for our managed VPN connection to on-premise. This ensures that there is no routing to other locations on the internet via our firewall. This will help to make it more closely resemble a MPLS/DX connection, where the edge device only has a connection to AWS (closest we can get in a lab).

Cisco ASA without a default route
Cisco ASA without a default route

The above shows that our on-premise firewall (172.17.0.1) has learned the following:

  • 10.10.0.0/16 (our AWS VPC) through BGP (indicated by “B”) from our VPN tunnels
  • 172.17.0.0/24 is directly connected because the ASA has a interface on this range
  • 172.17.1.0/24 (an on-premise VLAN where our client sits) through OSPF (indicated by “o”) from our network switch (172.17.0.2).
Switch showing no default route
Switch showing no default route

The above shows that our on-premise switch (which has multiple VLANs and interfaces 172.17.0.2 and 172.17.1.2) has learned the following:

  • 10.10.0.0/16 (our AWS VPC) through OSPF (indicated by “o2”) from our firewall redistributing its BGP routes into OSPF
  • 172.17.0.0/24 (internal vlan) is directly connected because the switch has a interface on this range
  • 172.17.1.0/24 (secure vlan) is directly connected because the switch has a interface on this range
AWS Public Route table - Pre
AWS Public Route table – Pre

The above route table is the route table for our public subnet where our cloud firewalls sit, as you can see the route table has learned a route to our on-premise networks, and also has a static default route set to the internet gateway of the VPC (this is part of what makes the subnet a public subnet).

AWS Private Route table - Pre
AWS Private Route table – Pre

Above is the private subnet route table for our AWS VPC. Like the public subnet, it has learned the on-premise networks, but its static default route is the ENI of the firewall. This directs internet traffic from our AWS servers through the firewalls for scanning and filtering.

Currently, only servers within AWS have full internet access and doing a “whats my IP” search shows the public IP of the firewall. Our on-premise network has no access to the internet as the ASA only knows how to get to our AWS VPN endpoints. Our on-premise workstation can ping our firewalls within AWS (due to all AWS subnets and on-premise subnets being shared) but cannot browse the internet. The below images confirm this.

On-premise client pingiing firewall in AWS
On-premise client pingiing firewall in AWS
On-premise client has no internet access
On-premise client has no internet access
AWS EC2 server in the private subnet has internet access through the cloud firewall (firewalls public IP shown)
AWS EC2 server in the private subnet has internet access through the cloud firewall (firewalls public IP shown)

Implementation

Provisioning our BGP VPN to our cloud firewalls.

Firstly, we need to provision a new VPN within our AWS environment from our cloud firewall:

  1. Within the AWS Portal:
  2. Navigate to the VPC services
  3. Navigate to “Customer Gateways”
  4. Create a new “Customer Gateway”:
    1. Give a name for the customer gateway for it to be identified
    2. Select “Dynamic” for routing type. This will ensure the connection uses BGP to share the routes we want.
    3. The BGP ASN needs to be unique, it cannot be the same as any other VPN or on-premise ASN’s. It must also be within the private ASN range. For our test, I’m setting the POC to 65100.
    4. IP Address, this needs to be the external/public IP of our firewall (as this is where the VPN is initiated from,

Note, it is important to ensure that the elastic IP of the cloud firewall is one that has been provisioned and assigned (if it was automatically given to the instance on start, it may change if the cloud firewall is rebooted).

Click “Create Customer Gateway”

Create CGW using public IP of our Cloud Firewall (Sophos UTM)
Create CGW using public IP of our Cloud Firewall (Sophos UTM)
  1. As we already have a VPG created and attached to our VPC, we don’t need to create a VPG
  2. Navigate to “Site-to-Site VPN Connections”
  3. Click “Create VPN Connection”
    1. Give an identifiable name for the VPN
    2. Select the target type as “Virtual Private Gateway”
    3. Select the virtual private gateway that is attached to the production VPC. This should be a VPG where your on-premise connections also terminate
    4. Select to use an existing Customer Gateway and select the customer gateway made in the above steps.
    5. Set the routing options to “Dynamic”
    6. Edit any additional IP ranges or settings you may need for your firewall vendor, for ours we can leave the rest as default.
    7. Click “Create VPN Connection”
Creating a BGP VPN for the Firewall back to the VPG
Creating a BGP VPN for the Firewall back to the VPG

This may take some time to provision, however while this is being setup (the status will show as “Pending”), you can select the VPN and download the configuration. For this lab, I will be selecting Sophos UTM.

VPN being provisioned
VPN being provisioned
Downloading VPN configuration
Downloading VPN configuration

With the configuration file for our VPN, we can either upload and run the vendor specific configuration file or implement the generic configuration file manually. As our cloud firewalls are an option in the vendor specific options, we chose to download this file in step 7. On our cloud firewalls:

On the cloud firewall, we can import this file directly through the GUI to implement our VPN with all BGP connections (I think this is a cool feature of Sophos UTM’s).

Importing AWS VPN on Sophos UTM
Importing AWS VPN on Sophos UTM

Within the GUI, there is an important box we need to pay attention to. This box provides us control over what routes we want to advertise form the firewall into the BGP VPN connection, aka what route we are going to inject into AWS.

Choosing what routes the Cloud Firewall advertises to AWS
Choosing what routes the Cloud Firewall advertises to AWS

As you can see in the above image, we have selected to advertise “Any” into the BGP connection, this is the reference Sophos uses for “0.0.0.0/0”. Without this, the default route would not be injected into the AWS to On-Premise connection.

TIP – Within Cisco devices, you may not be doing this in a GUI, and you would need to be doing this with a configuration similar to this:

router bgp 65100
  address-family ipv4 unicast
    neighbor 169.254.120.173 remote-as 9059
    neighbor 169.254.120.173 timers 10 30 30
    neighbor 169.254.120.173 default-originate
    neighbor 169.254.120.173 activate
    network 0.0.0.0
    no auto-summary
    no synchronization
  exit-address-family
exit

In the above Cisco example, I have highlighted the key parts of the config that allow you to advertise the default route into the VPN.

While we have been importing the VPN connection into Sophos, the AWS console now shows that the VPN status is has changed from “pending” (while its being created) to “Available”, which means its ready to connect.

We can verify the VPN on both ends:

On our cloud firewall (Sophos UTM), we can see the VPN connection has been established

Sophos showing that the VPN is established
Sophos showing that the VPN is established

Within the AWS portal (VPC -> Site to Site VPN Connections”) we select our Cloud Firewall VPN connection and see that both tunnels are up. We can also see that 1 BGP route is being advertised from the firewall into AWS. This will be our default route (Any) that was selected in the firewall GUI.

Cloud Firewall VPN's tunnels have both been established
Cloud Firewall VPN’s tunnels have both been established

Checking the routing within AWS

Now that we can see that the VPN is connected and is sharing BPG information, we can look on the route tables within AWS to see what the new route is. As the on-premise VPN/Direct Connect connection was already established, our private subnet already has “route propagation” enabled.

AWS Private subnet after Cloud Firewall VPN
AWS Private subnet after Cloud Firewall VPN

In the above image, we can see that there are now 2 routes to 0.0.0.0/0 within our route table:

  • 0.0.0.0/0 via eni-0a3a84e07e1ce858 Not Propagated (statically set).

This is the default route that points all our AWS servers traffic destined to the internet directly to the network interface of the cloud firewall.

  • 0.0.0.0/0 via vgw-06a4068e9ff5b9434 Propagated (advertised from our VPN).

This entry proves that our VPG is learning a default route from one of its connections (our cloud firewall VPN) and is also redistributing it to its other BGP neighbors.

In the above situation where AWS see’s 2 different routes to 0.0.0.0/0 the one we have set statically will always take priority over routes that have been propagated from the VPG. This will make sure that the AWS servers don’t use the VPN connection to go the internet as this has no benefit because they can get to the firewall directly.

Checking the routing On-Premise

Now we need to check our on-premise equipment to see that the default route has not only been advertised into the AWS route tables with propagation enabled, but also the other BGP enabled connections on the VPG.

Showing routes on our ASA firewall, we can now see that the firewall has 2 routes learned via BPG (indicated by the “B”). These routes are:

  • The default route (traffic to the internet) 0.0.0.0/0
  • Route to the AWS subnet
On premise ASA now has a default route learned from AWS VPN
On premise ASA now has a default route learned from AWS VPN

 Once we have verified that the BGP route has been learned by our customer gateway (Cisco ASA, our edge device), we need to check that our internal infrastructure also knows there is a default route. On our example, we have OSPF from the ASA to the internal infrastructure switches already configured. You may simply statically point a default route of your switches to the ASA/Edge device connecting to your AWS environment.

Showing the routes on our switch, we can see that a default route has been advertised as through our Cisco ASA/Edge device using OSPF (indicated by the “o2” flags).

On premise switch showing default route from the ASA is being distributed via OSPF
On premise switch showing default route from the ASA is being distributed via OSPF

It now looks like our on-premise infrastructure understands and knows to send all unspecified traffic through our AWS connections. It’s time to test!

Testing the deployment

Now that we have verified that our on-premise networks have a default route being learned from our AWS infrastructure, its time to check our connectivity, and check that our clients public IP shows as the cloud firewalls we are using to NAT them to the internet.

The firewall has been configured to allow the on-premise network range to have internet access via the web filtering service it provides. For our final check, we need to ensure when browsing the internet, the linux appliances traffic appears to come from the cloud firewall’s public IP. Below we verify the public IP of the firewall:

Cloud Firewall public IP address (EIP)
Cloud Firewall public IP address (EIP)

Using our Linux client connected to our on-premise switch, we are able to ping 8.8.8.8 (google DNS) and also, we are able to browse the internet. If we check what our public IP is when browsing the internet, it verifies that our IP address is: 3.10.121.76 which is the public EIP assigned to our cloud firewalls. This is the same IP shown when we did the same check earlier from our AWS servers within our VPC.

On premise linux client showing its public IP matches the firewall
On premise linux client showing its public IP matches the firewall

Notes and Costs

Cost

The main additional cost to your infrastructure when looking to implement the above solution is the cost of the AWS managed VPN that is used to inject the default route into the VPG. The charges for this connection are in 2 parts (additional charges apply if you decide to use the VPN accelerator service to bring your AWS VPN endpoint as close as possible):

  1. Connection Charge (per hour), this is a on-going charge for the VPN from the time of creation to when you terminate it
  2. Data transfer charge, these chargers are for data out of AWS (data into AWS is generally free). Its important to make sure your routing is correct (ie: that VPC traffic doesn’t use the VPN when it can use the ENI of the firewall) to avoid unnecessary charges (see below).

The other key cost to completing this type of traffic flow, is to remember you will pay for your egress of internet traffic, if you previously had your AWS servers using AWS as a egress point, you will pay for the extra internet traffic of your on-premise servers.

Notes

Some firewalls may not allow asynchronous routing out of the box as they often use connection tracking to only allow connections that it saw the initial packets of which can cause problems when traffic comes in or out through a different path on the firewall. If it becomes an issue, it can often be disabled, or making some additional routing decisions and adjustments this can be avoided.

Firewall VPC to Internet after Firewall VPN established

You should check the firewall’s own route table (AWS subnet route table and its own devices route table) to avoid asynchronous routing, when it’s trying to reach devices in other subnets in the same VPC. Most likely, the only routes the firewall will know by itself, will be its own subnet, and a default route (0.0.0.0/0) through its adapter, which is how it would have initially sent traffic for other subnets in the VPC (using the default route), however now we have a BGP VPN, it would have learned a more specific route to the wider VPC its located in to be via the VPN (along with our on-premise routes). I would expect the following traffic flow:

  1. AWS Server
  2. Cloud Firewall Local Interface
  3. Internet
  4. Cloud Firewall (return traffic)
  5. VPN
  6. VPG
  7. AWS Server

In order to check that the above doesn’t happen, make sure that (and this can vary depending on your firewall vendor), you add a static route on your device to the VPC’s complete range to be the AWS gateway (.1 address) of the subnet your firewall resides in. Hopefully this will make your firewall deem routes to its own VPC learned from the VPN as less preferable restoring the original traffic flow. For Sophos, I had to use policy-based routing in order to set the next hop as the .1 address.

  1. AWS Server
  2. Cloud Firewall Local Interface
  3. Internet
  4. Cloud Firewall Local Interface
  5. AWS Server

On-Premise client to internal address of CloudFirewall after Firewall VPN established

Another important note to check and understand about the possible routing path that may occur when using the firewalls in the same VPC as your on-premise connection is terminated.

When an on-premise device wants to talk to the internet, the following path will happen:

  1. On-Premise Client requests a internet destination such as 8.8.8.8
  2. On-Premise network
  3. On-Premise Firewall or customer router at edge
  4. On-Premise VPN or Direct Connect Connection
  5. VPG

As the VPG has nothing more specific than the default route for the destination 8.8.8.8 it will use the VPN advertising the default route (our Cloud Firewall VPN).

  1. CloudFirewall VPN
  2. CloudFirewall
  3. Internet Destination
  4. CloudFirewall

As the firewall learns routes to the on-premise network from our firewall VPN, it will use this path for the return traffic.

  1. CloudFirewall VPN
  2. VPG
  3. On-Premise VPN or Direct Connect Connection
  4. On-Premise Firewall or customer router at edge
  5. On-Premise network
  6. On-Premise Client

However, the following asynchronous routing may occur when the on-premise client wants to talk to the internal address of the firewall (to manage the firewall or ping checks etc)

  1. On-Premise Client wants browse the HTTPS GUI of the firewall using its internal VPC address
  2. On-Premise network
  3. On-Premise Firewall or customer router at edge
  4. On-Premise VPN or Direct Connect Connection
  5. VPG

As the VPG is attached directly to the same VPC and knows about the subnet that the firewalls internal address is in, it will not use the default route of our cloudfirewall VPN and route the traffic into the VPC directly

  1. VPC router
  2. CloudFirewall

As the firewall learns routes to the on-premise network from our firewall VPN, it will use this path for the return traffic instead of the incoming path of the VPC.

  1. CloudFirewall VPN
  2. VPG
  3. On-Premise VPN or Direct Connect Connection
  4. On-Premise Firewall or customer router at edge
  5. On-Premise network
  6. On-Premise Client

As this is only an issue for traffic destined to the firewalls internal address, the most reliable and cost-effective method, would be to add the firewalls internal address as an address to be advertised into the firewall VPN. This would mean that at traffic point 5 above, to get to the firewalls internal address, it would use the firewall VPN instead of going through the VPC router, making the inbound and outbound path the same. You should add the firewalls IP and not the subnet of the firewall to ensure it only applies to a specific address.

Although the above route would also be advertised into the AWS route tables, it will be less preferred than the static local entry for the VPC subnet range (providing this has not been removed).

Looking to Migrate to Transit Gateway

As mentioned, Transit Gateway is AWS’s new method of controlling routing domains (we will look at this in upcoming article) and the above solution is a method of achieving on-premise internet routing via AWS if you are not looking to make the move to Transit Gateway. This may be because your DX and on-premise VPN connections all terminate on your production VPC and you want to make as little change as possible.

However, what if you know you want to move to transit gateway in the future and want to start building into this solution, but again, don’t yet want to move your primary links from your production VPC. To help remove the need to rebuild your cloud firewalls when moving to transit VPC, I would recommend the architecture following change to the above solution.

Preparing for Transit Gateway
Preparing for Transit Gateway

The change we have made above, is simply creating the transit/egress VPC that will be used when using transit gateway, and implementing the firewalls in this location. The VPN from the firewalls will still terminate on your production VPC. Once your transit gateway solution is inplace, this VPN can be removed and replaced with a VPC attachment for Transit Gateway.

Useful Links

For more information on AWS VPN Pricing:

https://aws.amazon.com/vpn/pricing/

Working with AWS VPN’s:

https://docs.aws.amazon.com/vpn/latest/s2svpn/working-with-site-site.html

Information on Generic VPN Configuration files:

https://docs.aws.amazon.com/vpc/latest/adminguide/GenericConfig.htmlAWS

Routing tables

https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Route_Tables.html

Sophos UTM on AWS Marketplace:

https://aws.amazon.com/marketplace/pp/Sophos-Sophos-UTM-9-PAYG/B00DJDRZB2

GNS3 (virtual network infrastructure):

https://www.gns3.com/