diff --git a/aws/documentation/transit-gateway/lab-dmz.md b/aws/documentation/transit-gateway/lab-dmz.md new file mode 100644 index 00000000..f53b05dc --- /dev/null +++ b/aws/documentation/transit-gateway/lab-dmz.md @@ -0,0 +1,166 @@ +# Lab DMZ Networking + +# Links + +* [DMZ Tunnel Tracker](dmz-vpn-tunnel-tracker.csv) +* [Lab](lab.md) + +## Concepts and Capabilities + +* needed environment segments + * common/services/shared + * test +* create new VRFs for lab-dmz-X above +* establish network addressing blocks for the TGW connections +* determine where to place the Lab DMZ networking (existing TGW, new TGW and peering) + * we have decided a separate account and new TGW +* network addressing for subnets used in Lab DMZ, both regions +* creating VPN configurations for at least 2 vpn connections (4 tunnels, 2Gbps aggregate) per env per site per region + * these come from templated code built from VPCs attached to TGW +* understand connectivity requirements. This will be something per application + * from on prem + * from current aws (now called "lab-internal") + * from internet (while not available, it is important to know) + * to on prem + * to current aws + * to internet +* establish and document general security pattern for apps in Lab DMZ consistent with on-prem + * extremely limited to no inbound access (inbound to internal on prem or cloud) + * ok with on-prem dmz + * prefer/recommend outbound (from on prem or internal aws) to dmz + * all components reside in the DMZ (multi-tier, middle, DB) + * no direct access to internal on prem or aws DBs +* all these "to" will be limited as we treat this as an actual Lab DMZ vs Lab AWS current as an extension of the network +* these connections to current aws stuff will be quite a challenge as we cannot just route from one env to a dmz env without some sort of FW +* how will dns work within this new isolated configuration + * sharing of route53 inbound endpoints + * outbound endpoints + * view-like capability, where zone in the dmz has diff data from a zone internal +* new OU for DMZ, not sure at what level + +## Architecture + +The TGW architecture will be multi-region, and generally is configured as follows: + +1. New AWS account lab-gov-dmz-network-nonprod +1. TGW in each region +1. Share TGWs to Lab-GOV-DMZ OU +1. TGWs peer to each other +1. One VPC per environmment (enclave) per region, currently (lab by definition is not stage or prod, and no dev in DMZ): + * common, services, shared (dmz-common) + * test (dmz-test) +1. A new VRF on-prem for each of the above environments (lab-dmz-services, lab-dmz-test) +1. Each VPC has a small /23 IPv4 CIDR block. No workloads will be permitted here, but we are allocating some address space for both connectiity and +performance testing, as well as for some potential future use. Each is comprised of: + * /28 tgw-attachment subnets, one per AZ (up to 8, using a /26 for this), where the attachment is the only thing on the subnet + * /28 endpoint subnets, one per AZ (up to 8, using a /26 for this), for a maximum of 12 endpoints (this should a small number of endpoints) + * /26 apps subnets, one per AZ (up to 8, using a /24 for this), for testing and performance related activities. +1. (TBD) Each VPC will be assigned a /56 IPv6 CIDR block. The same configuration applies as above, with the exception that each subnet is a /64 + * tgw-attachments subnets (aggregated to /61, allowing 8 AZs) + * endpoint subnets (aggregated to /61, allowing 8 AZs) + * apps subnets (aggregated to /61, allowing 8 AZs) + * free space, next /61 + * free space, remainder of blocks +1. One VPC route table per VPC for tgw-attachments +1. One VPC route table per VPC for everything else +1. One TGW route table per VPC (environment/enclave) +1. One TGW route table per environment/enclave +1. One TGW route table per region for inter-region traffic (to reach other region(s)) +1. For IPv4, Two or more VPNs per site (BCC, HQ) per environment/enclave, through DirectConnect. Initial proposal is (18): + * common 2 + * test 2 +1. (TBD) For IPv6, repeat the setup as with IPv4. VPN tunnels for IPv6 use only IPv4 endpoints, but carry IPv6 traffic. + +## Diagrams + +![Transit Gateway with Lab DMZ](images/tgw-networking-lab-dmz.png) + +## TGW Configurations + +* lab-dmz-network-nonprod + +Because we need to establish the same network connectivity like we have for the Lab AWS "internal", we will create a TGW configuration in for the Lab DMZ + +## Network Allocation :: Lab DMZ GovCloud + +(UPDATE NEEDED) + +We need a 10.x/14 block (4 consecutive 10.x/16 blocks) for the DMZ, minimally. + +1. East 10.{x}/15 +2. West 10.{x+2}/15 + +For each of these blocks, we will have this layout. We can also consider using a completely different CIDR for the TGW attachment blocks, for +which we will need another /16. Ideally, it would be aggregatable to the "DMZ" set of networks. + +1. TGW attachment and supporting configurations as /23 blocks (usually), allows for 16 /23s or a mixture of that and larger, in us-gov-east-1 10.136.0.0/19 and us-gov-west-1 10.136.32.0/19 + 1. 0.0/23 dmz-tgw-common + 1. 2.0/23 dmz-tgw-test + 1. 8.0/22 dmz-tgw-endpoints + 1. 12.0/22 (free) + 1. 16.0/21 (free) +1. Shared VPCs are in us-gov-east-1 10.132.0.0/15 and us-gov-west-1 10.134.0.0/15 + 1. 0.0/20 dmz-services + 1. 16.0/20 dmz-common + 1. 32.0/20 dmz-shared + 1. 48.0/20 (free) + 1. 64.0/19 dmz-test +1. The next block 10.{x+1} is for expansion + +# Network Assignments :: Lab DMZ GovCLoud + +## Assignments + +## TGW Attachments + +## TGW Attachment VPCs + +* us-gov-east-1 + +* us-gov-west-1 + +## Shared VPCs + +* us-gov-east-1 + +* us-gov-west-1 + +## TGW Route Tables + +Just as in the AWS internal configuration, we will have a TGW route table for each environment, and another one for the the VPN per environment: + +1. dmz-tgw-common +1. dmz-tgw-test +1. vpn-dmz-tgw-common +1. vpn-dmz-tgw-test + +VPN connectivity will be established to each of these. + +We will allocate new [tunnel collection numbers](tunnel-numbers.md#values-tunnel-collection) and new [environments](tunnel-numbers.md#values-environment) for the DMZ. +These will be used for the new tunnel numbers. + +Each of the new VPNs will have a new ASR endpoint. We may wish to shut down some old tunnels to make way for new addresses. We will need one ASR public IP +per each environment per region per site. So, 8 148.129.163.x for HQ tunnels (4 west, 4 east) and 8 148.129.78.x for BCC tunnels (4 west, 4 east). + +## Routing + +We will use managed prefix lists, shared to the DMZ accounts, for routing. One list will be for VPN back to on-prem, which should contain the list of available +CIDR blocks via VPN. I do not know if connectivity to any Azure networks are required, though it is possible the common services may need so for +various AD or ADFS communications. + +As with the AWS internal configuration, all DMZ environment are routable to the services/common networks, and then only to their own environment (stage to stage, etc.). + +Routing between DMZ and non-DMZ will require some research and design work. It is likely to be an inspection-type VPC with AWS firewall and Gateway Load Balancers. +Short term may use AWS PrivateLink to expose specific things within the internal AWS environment. + +We are likely to see blackhole routes used for this DMZ configuration to prevent traffic flowing where we don't want it. + +## TGW Peering + +This will create two sets of TGWs, one set in non-DMZ and one in DMZ. We want connectivity among these to go through some security capability. Early +testing of this setup may involve using TGW peering among all 4 TGWs and specific routes on the TGW route tables to/from the systems (through prefix lists). + +# CHANGELOG + +* 1.0.0 -- 2025-01-30 + - copy from dmz.md