DirectConnect with Transit Gateway and best practices to inspect traffic and connect back to on-premises

I am going to discuss pros/cons and best practices to use DirectConnect with Transit Gateway , DirectConnect Gateway and Network Firewall.

DirectConnect doesn’t provide traffic encryption (by default) and only secure ports should be allowed. You can enable Macsec encryption for 10G and100G DX connections.

Solutions to connect from on-premises to cloud and vice-versa:

  1. IPSEC tunnel over Internet i.e. ec2 instance in AWS VPC -> on-premises firewall.

→ Creating High available ec2 instances and route traffic when one of the ec2 instance terminates is bit challenging. Need to use lambdas/scripts to alter route table and redirect traffic to another ec2 instance ENI.

→ IPSEC bandwidth relies on IPSEC ec2 instance type. e.g. openswan/PAN/SRX etc.

→ Patch/maintain/manage IPSEC ec2 instances.

→ It uses internet; so connection reliability is not great. There can be packet losses/connection deterioration etc.

2. Use DirectConnect with IPSEC tunnels:

→ Directconnect link provides reliability and IPSEC provides all traffic encryption.

→ IPSEC limitation of 1.25Gbps i.e. bandwidth per VPN tunnel.

→ Create rules/ACL’s in on-premises firewall to allow traffic; default is deny all.

→ Create at least 2 tunnels from AWS to on-premises — HA purposes

→ Whenever we create a new AWS account you need to create these IPSEC tunnels from each VPC and then it needs to be configured at on-premises firewall as well.

3. Use DirectConnect with Transit Gateway and DirectConnect Gateway:

→ This is better approach as it unlocked bandwidth limitation.

→ Transit Gateway can be created and shared with multiple accounts using Resource Access manager. You can use Org-ID and share with all accounts at once.

→ Accounts need to change route table and use transit gateway attachment for particular routes/prefixes.

→ Issue with this approach is you need to rely on security groups and NACL’s (Network access control list) i.e. to allow traffic from on-premises to AWS and vice versa.

→ If you have 100 VPC’s then managing NACL’s per VPC is challenging.

→ NACL can restrict/allow traffic based on IP address and not domain names. Imagine if we need to allow google.com or any other domain from VPC’s. It can be nightmare/unmanageable for multiple accounts. As the IP’s keep on changing and you need to edit NACL’s accordingly.

→ For one account you can probably create a lambda that perform IP resolution and then add results to NACL but there are limitations with this approach.

4. Use DirectConnect with Transit Gateway, DirectConnect Gateway and Network firewall:

→ This seems the best approach but the only major downside is pricing.

→ Similar to above scenario but we are adding Network Firewall i.e. centralised Firewall for all VPC’s. We can allow/deny traffic based on domain names.

→ Create and manage rules in Network firewall. It acts as layer 3–7 with Intrusion prevention, packet flow inspection.

Source: AWS

→ It can also be used to filter/apply firewall policies to egress traffic as well i.e. to internet.

→ Major downside is pricing as AWS will charge for fixed prices and GB’s processed as well.

→ There are throughput limitations/prefix allowed at Transit Gateway/DirectConnect Gateway and Network firewall as well. In those cases, we need to replicate this setup for another set of VPC’s.

With Transit Gateway and Network firewall setup you can restrict/inspect traffic for below use cases:-

→ VPC peering.

→ DirectConnect Traffic to on-premises.

→ NAT Gateway Traffic to external websites.

This Network Firewall can also be replaced with any other Firewall vendors such as Juniper/PAN’s etc. but these needs to be automatically scale up and down in case of traffic surge.

Centralising egress traffic filtering for both Internet and internal make sense and you can also apply some automated preventive measures. E.g.:- We can write guardduty actions to block any TOR or vulnerable address for all VPC’s at once.

The only disadvantage is high costs associated with this additional inspection VPC setup.

5. Rely on Security Groups at Scale with Network Firewall Manager + Route53 DNS Firewall — Detect and rollback changes.

→ We can rely on strict ingress/egress security groups and manage them at scale using Firewall Manager. It has all the abilities to detect changes/alert and rollback security groups.

→ Use Route53 DNS Firewall to block DNS resolution for on-premises hosts.

→ Apply host based firewall (such as iptables) or so at on-premises to block requests from Cloud or any other source.

Best Security Practices:

→ Dedicated DirectConnect AWS account. All changes via config management tools.

→ Monitor Cloudwatch rules for NACL level changes and alert to security team for any changes via SIEM tool.

→ Use latency analysis/bandwidth degradation tools from AWS to on-premises and vice-versa. It will help us checking for any connection deterioration from VPC level.

→ Check all ingress/egress traffic using VPC flow logs for insecure ports. Block insecure ports at NACL level.

→ Route53 Resolver DNS Firewall : This can be done to block DNS resolution at VPC level. We can set DNS response i.e. NXDomain/Nodata/Override (with different IP). Be noted that it’s for protection against general DNS security/bots. If anyone gains access to ec2 then it can reach destination via IP address OR simply by editing hosts entry.

→ Enable Firewall Protection for public S3 access from on-premises.

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store