Skip to content

Instantly share code, notes, and snippets.

Below is one cohesive example showing how to set up two Network Firewalls (one in NP MEL, one in NP SYD) and a CloudWAN policy that enforces traffic from the NP MEL prot segment to the NP SYD prot segment (and vice versa) to pass through both the NP MEL prot firewall and the NP SYD prot firewall.
Important Notes
1. We are not including VPC creations or VPC attachments—only the firewall resources and the CloudWAN policy references.
2. The code demonstrates a sample approach to modules and file structures. You can adapt naming and values to match your real environment.
3. The CloudWAN policy JSON is simplified but illustrates the essential concept of multiple firewalls in a strict path.
1. Directory Structure
Below is a proposed layout. You can adjust file names as needed, but this structure keeps things organized:
Below is a conceptual guide to how AWS Network Firewall fits together with CloudWAN service insertion, answering common questions about subnets, firewall VPC design, and how the various AWS Network Firewall resources (firewall, firewall policy, logging config, resource policy, rule groups) work together in Terraform.
1. How Many Subnets Does a Firewall VPC Need?
When using AWS Network Firewall in a “service insertion” scenario with CloudWAN, you typically need one dedicated subnet per Availability Zone for the firewall endpoints. Each of those subnets hosts a firewall endpoint in that AZ.
• Minimum: 1 subnet in each AZ you want covered by the firewall.
• High Availability: If you need multi-AZ redundancy, you create a subnet in each AZ (e.g., AZ-a, AZ-b, AZ-c).
Do We Also Need a “Transit” Subnet?
Below is a complete example of how to implement AWS Network Firewall with separate rule group resources, a single firewall policy, and a lightweight firewall module—all while enforcing CloudWAN service insertion policies. We’ll illustrate:
1. A firewall module that only creates the firewall itself.
2. NP MEL prot firewall example:
• Multiple rule groups with different Suricata rules.
• A single firewall policy referencing those rule groups.
• A firewall resource (instantiated via the module).
3. A CloudWAN routing policy JSON showing how traffic is forced (via “STRICT” mode) to the NP MEL prot firewall segment.
Note: Adjust resource names and IDs to match your actual environment.
We focus on the NP MEL protected firewall scenario, but you can replicate the pattern for ext, int, or other environment/region combos.
Below is a complete example of how to implement AWS Network Firewall with separate rule group resources, a single firewall policy, and a lightweight firewall module—all while enforcing CloudWAN service insertion policies. We’ll illustrate:
1. A firewall module that only creates the firewall itself.
2. NP MEL prot firewall example:
• Multiple rule groups with different Suricata rules.
• A single firewall policy referencing those rule groups.
• A firewall resource (instantiated via the module).
3. A CloudWAN routing policy JSON showing how traffic is forced (via “STRICT” mode) to the NP MEL prot firewall segment.
Note: Adjust resource names and IDs to match your actual environment.
We focus on the NP MEL protected firewall scenario, but you can replicate the pattern for ext, int, or other environment/region combos.
Below is a comprehensive walkthrough:
1. Check for typos or abnormal paths in your list.
2. Devise a strategy to handle many chained flows (service insertion).
3. Show a “full” CloudWAN policy JSON (using latest syntax) with symmetric routes from NP-MEL-ext-seg to all other segments you listed.
Important: Because your design has many segments and each route can chain multiple firewall segments, the final JSON will be very large. Below, I’ll fully enumerate only the routes from NP-MEL-ext-seg to all others—plus the symmetric reverse routes. In reality, you’ll expand the same pattern for other “source” segments (e.g., NP-MEL-int-seg, NP-SYD-ext-seg, etc.) as needed.
1. Check for Typos or Abnormal Points
From your list:
We couldn’t find that file to show.
We couldn’t find that file to show.
@huynhbaoan
huynhbaoan / tfw
Last active March 1, 2025 12:32
Tfw
DIR_PATH=$(pwd | sed 's%^.*account-build%account-build%g')
AWS_SHORT_ACCOUNT_ID=$(echo ${DIR_PATH} | /bin/awk -F "/" '{print $2}')
APPACC_ID=$( cat account-variables.tf | tr '\n' ' ' | sed -e 's/.*variable[ \t]*"account-id"[ \t]*{[ \t]*default = "\([0-9]*\)"[ \t]*}.*/\1/g' )
STACKNAME=$(basename "${DIR_PATH}")
AWS_ACCOUNT_NUMBER=$(aws sts get-caller-identity --query 'Account' --output text)
S3_CF_BUCKET="${AWS_ACCOUNT_NUMBER}-config"
CORRECT_ACC_FLAG="false"
ACCOUNT_TYPE=$( cat account-variables.tf | grep account-type | awk -F '"' '{print tolower($4)}' )
ROLE_NAME=$(aws sts get-caller-identity | jq '.Arn' | awk -F "/" '{ print $2 }')
APPACC_NAME=$(cat account-variables.tf | grep account-shortname | awk -F '"' '{print tolower($4)}')
fields @message
| parse @message " * * * * * * * * * * * * * * *" as version, account_id, interface_id, srcAddr, dstAddr, srcPort, dstPort, protocol, packets, bytes, start_time, end_time, action, log_status
| filter dstPort = 25 or dstPort = 465
| filter dstAddr in ["10.39.132.10", "10.39.133.138", "10.39.132.97", "10.39.133.151"]
| limit 10000
fields @timestamp, @message
| parse @message " * * * * * * * * * * * * * * *" as version, account_id, interface_id, srcAddr, dstAddr, srcPort, dstPort, protocol, packets, bytes, start_time, end_time, action, log_status
| limit 10