DMZ setup on Transit VPC (AWS)

Reply
Highlighted
L1 Bithead

DMZ setup on Transit VPC (AWS)

I'm just wondering if anyone setup a DMZ on Transit firewalls in Transit VPC on AWS? Basically we need to have outbound to inbound NAT rule with a elastic ip address. Came across this link but not sure if this is the proper way of doing it. We would like achieve this through a dedicated VSYS but open for different options.

Highlighted
L4 Transporter

We would typically recommend a different set of firewalls for inbound traffic outside of the Transit Firewalls.  They would then either sit in the VPC with the application or connected to the VPCs via a peering link.  This is to alleviate the fact that Transit VPC firewalls are active/passive in terms of routing load and an inbound design is active/active resulting in a possible overloaded firewall.

 

Knowing that this is not always feasible.  You can use a public-facing ALB/NLB in front of the firewalls and then SNAT to address that has been distributed via BGP to the spokes.  This would either be one of the Ethernet addresses or a loopback.  Do not SNAT to the tunnel address as they are not fault-tolerant on a tunnel failure.

Highlighted
L1 Bithead

@jmeurer  Do you happen to have the documentation or link which could guide me on your purposed solution?

Highlighted
L4 Transporter

There is nothing public-facing that directly lines up.  This is more of a blending of a couple of designs.  It would be beneficial to engage with your account team to have a more tailored conversation to your specific needs.

Highlighted
L1 Bithead

@jmeurer On the page 12 of the aws-transit-vpc-model-deployment-guide  there is a way to create an inbound NAT on Transit firewalls. My question is how can you ensure that same elastic ip address is failed over to the other firewall just in case if it looses connectivity the subscriber VPC which is being used for destination NAT. We would like to leverage our existing Transit VPC setup to see if it fulfills our needs.

Highlighted
L4 Transporter

The design on page 12 of that guide utilizes a separate set of firewalls in the spoke VPC that are dedicated to the inbound traffic for only that spoke VPC.  This design is different than bringing inbound traffic in through the Transit VPC.  In either scenario, the EIP/FQDN is assigned to the public-facing load balancer, it is not released if a link is down.  The design you are looking for is not in that guide.  It would be best communicated through your Systems Engineer.

Like what you see?

Show your appreciation!

Click Like if a post is helpful to you or if you just want to show your support.

Click Accept as Solution to acknowledge that the answer to your question has been provided.

The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!

These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the Live Community as a whole!

The Live Community thanks you for your participation!