AWS Network Firewall is a managed, stateful network firewall and intrusion protection service that allows you to implement firewalls rules for fine grained control over your network traffic. If you’re new to AWS Network Firewall, and want to understand its features and use cases, we recommend you review the blog post AWS Network Firewall – New Managed Firewall Service in VPC.

In this post, we show how you can use AWS Network Firewall in dual stack and IPv6-only environments. We detail differences in deployment models, considerations with IPv6 environments, and tradeoffs. If you are interested in deployment models for IPv4-only networks, they are discussed in the post Deployment models for AWS Network Firewall.

IPv6 dual stack support was added to AWS Network Firewall in January 2023, and IPv6-only support was added in April 2023. You can find more resources on IPv6 best practices, reference architectures, and documentation in the re:Post article Get started with IPv6 on AWS.

IPv6 deployment models on AWS

When deploying IPv6 environments on Amazon Web Services (AWS), there are two main options for deployment: dual-stack and IPv6-only. In a dual-stack model, your environment supports both IPv4 and IPv6, while IPv6-only means that workloads have only IPv6 addresses configured.

Dual-stack deployment model

A dual-stack deployment model has an environment that supports both IPv4 and IPv6 traffic. Resources in your environment have both IPv4 and IPv6 addresses. A benefit of deploying dual-stack environments is the native backward compatibility with resources not supporting IPv6. For example, you may have clients that are IPv4-only, so native IPv4 connectivity to a dual-stack endpoint is possible on IPv4.

IPv6-only deployment model

In an IPv6-only environment, your resources have only IPv6 addresses and can only send and receive IPv6 traffic. An IPv6-only model can be selected after ensuring clients, AWS services, and third-party resources support IPv6 or a backward-compatibility layer is configured. For example, you can deploy IPv6-only Amazon Elastic Compute Cloud (Amazon EC2) instances for a service in your virtual private cloud (VPC) and use a dual-stack load balancer to allow both IPv4 and IPv6 clients to access the service.

Let’s review the common architecture patterns for AWS Network Firewall in IPv6-enabled environments.

Internet ingress inspection architecture patterns

In this section will explore how you can use AWS Network Firewall to inspect IPv6 internet ingress traffic. AWS Network Firewall can be used in a distributed or centralized model.

IPv6 distributed -internet ingress inspection

In the first scenario, we focus on external clients connecting to an application hosted on AWS and using IPv6, as shown in the following diagram (Figure 1).

Figure 1: IPv6 internet ingress pattern

(1) The dual stack Application Load Balancer maintains both A (IPv4) and AAAA (IPv6) fully qualified domain name (FQDN) records in Amazon Route 53 to allow both IPv4 and IPv6 clients access to your application. You can create a Route 53 public hosted zone for your custom DNS names, create both A and AAAA alias records, and point them to the Application Load Balancer FQDN.

(2) Your IPv4 and IPv6 clients receive the A or AAAA records, depending on the DNS queries they perform, based on their capabilities.

(3) Internet ingress traffic is inspected by AWS Network Firewall with endpoints in dual-stack subnets.

(4) Ingress routing functionality uses gateway route tables, allowing AWS Network Firewall to be inserted in the traffic path between the internet gateway and your application.

(5) The traffic destination is your Elastic Load Balancer (ELB), and the firewall acts as a bump-in-the-wire model inspection resource, transparent to the client and application.

(6) After inspection, traffic is forwarded to your load balancer without any changes in IP addresses (IPv4 or IPv6).

(7) The ELB then sends traffic to your backend EC2 instances on the protocol version they support, either IPv4 or IPv6. A dual-stack load balancer supports both IPv4 target groups and IPv6 target groups.

This model supports both Application and Network Load Balancers, and AWS Network Firewall can filter both IPv4 and IPv6 traffic.

AWS Network Firewall configuration

The following example shows standard stateful rules allowing HTTP port 443 to the ELB subnet and blocking HTTP port 80 traffic. Customers can also use Suricata compatible rules.

Figure 2: Standard stateful rules configuration allowing HTTP port 443

An example of a Suricata rule to allow ingress traffic to IPv6 Classless Inter-Domain Routing (CIDR) is shown in the following code snippet:

pass tcp any any -> [2600:1f14:f25:df00::/56] 443 (flow:established,to_server; msg:"Allow TCP 443 traffic"; sid: 1000005; rev:1;)

IPv6 centralized internet ingress inspection

Centralized internet ingress patterns are limited in IPv6 to dual-stack applications and Network Load Balancers with IPv4 targets in other VPCs. Currently, you cannot configure IP-type target groups containing IPv6 addresses of your workloads residing in other VPCs or in on-premises networks, even if private connectivity is configured using VPC peering, AWS Transit Gateway, AWS Cloud WAN, or AWS Direct Connect.

However, if you wish to have IPv6 targets and IPv6 services, you can centralize internet ingress using dual-stack Elastic Load Balancers and IPv6 targets by using IPv6 IP-type targets as the dual-stack AWS PrivateLink endpoints in the centralized ingress VPC. The PrivateLink endpoints allow your front-end Application or Network Load Balancer to connect using IPv6 to services in other VPCs or your on-premises network.

Figure 3: IPv6 centralized internet ingress with PrivateLink pattern

AWS Network Firewall configuration

When you configure Network Firewall policy variables for a firewall policy, you can add one or more IPv4 or IPv6 addresses in CIDR notation to override the default value of Suricata HOME_NET. If your firewall is deployed using a centralized deployment model, you might want to override HOME_NET with the CIDRs of your inspection VPC, as shown in the following diagram (Figure 4).

Figure 4: AWS Network Firewall HOME_NET configuration

Internet egress inspection architecture patterns

As you deploy workloads in AWS, many resources will need access to the internet. This traffic often must be inspected. This section will explore two options for inspecting egress to the internet for your AWS resources.

IPv6 distributed internet egress inspection

Workloads deployed in dual-stack or IPv6-only subnets connect to internet endpoints using either IPv4 or IPv6, and the traffic can be inspected using AWS Network Firewall for both IPv4 and IPv6. As shown in the following diagram (Figure 5), we deploy AWS Network Firewall endpoints in a dual-stack subnet to allow traffic inspection of both IPv4 and IPv6 protocols.

Filtering IPv6 egress traffic using AWS Network Firewall is possible today only for public subnets. Private IPv6 subnets are configured with a default route to the egress-only internet gateway, which doesn’t support ingress routing capabilities, to allow for symmetrical inspection of the return traffic through the firewall endpoints.

Figure 5: IPv6 distributed internet egress inspection

Using an internet gateway for egress means that in IPv6, the subnets are public. Therefore, appropriate restrictions should be applied on AWS Network Firewall for blocking internet originated ingress traffic to the workload subnets.

NAT64 and DNS64 to communicate with IPv4-only services

If you have subnets with IPv6-only workloads that needs to communicate with IPv4-only services on the Internet you can use AWS managed DNS64 together with NAT64. If there is no IPv6 address associated with the destination in the DNS record, the Route 53 Resolver synthesizes one by prepending the well-known prefix 64:ff9b::/96 (defined in RFC6052), to the IPv4 address in the record. Your IPv6-only service sends network packets to the synthesized IPv6 address. You will then need to route this traffic through the NAT gateway, a Network Address Translation (NAT) service, which performs the necessary NAT64 translation on the traffic to allow IPv6 services in your subnet to access IPv4 services outside that subnet.

You can enable or disable DNS64 on a subnet using the aws ec2 modify-subnet-attribute command using the AWS CLI or with the VPC console by editing the subnet settings. NAT64 is automatically available on your existing NAT gateways or on any new NAT gateways you create. For more information see the DNS64 and NAT64 documentation.

As shown in figure 5, firewall endpoint subnets have route for 64:ff9b::/96 pointing towards the NAT gateway, this is required for NAT64 to work.

AWS Network Firewall configuration

Example Suricata rule to block ingress traffic to IPv6 CIDR:

drop ip any any -> [2600:1f14:f25:df00::/56] any (flow:established,to_server; msg:"Deny IPv6 traffic"; sid: 1000006; rev:1;)

Note that you can combine two models: IPv4 centralized egress and IPv6 distributed egress.

IPv6 centralized internet egress inspection

To implement the centralized IPv6 internet egress pattern, you must use NAT66 or IPv6-to-IPv6 Network Prefix Translation (NPTv6) capable firewalls or proxies, together with Gateway Load Balancer, deployed in two-arm mode. The Gateway Load Balancer two-arm deployment model is explained in the blog post Best practices for deploying Gateway Load Balancer. When possible, we recommend that you implement a distributed egress pattern, discussed in a preceding section, to improve scalability and optimize data processing costs.

VPC-to-VPC traffic inspection deployment patterns

Let’s explore how you can use AWS Network Firewall to inspect IPv6 traffic between different environments or security zones on AWS. AWS Network Firewall can be used in a centralized or distributed model in this pattern. You can inspect IPv6 traffic within a VPC, for example, from a private subnet to a public subnet, or between VPCs.

Centralized VPC-to-VPC inspection pattern with Transit Gateway and AWS Cloud WAN

You can use a centralized VPC to deploy AWS Network Firewall and route traffic to the central firewall deployment using AWS Transit Gateway or AWS Cloud WAN. This model is discussed in the Centralized Deployment section of Deployment models for AWS Network Firewall for Transit Gateway and Inspecting network traffic between Amazon VPCs with AWS Cloud WAN. To use this architecture in a dual-stack environment, you need Transit Gateway or AWS Cloud WAN dual-stack VPC attachment subnets, and you must update your route tables to include the appropriate IPv6 routes. The following diagram (Figure 6) shows an example of AWS Transit Gateway deployment:

Figure 6: Centralized VPC-to-VPC inspection with Transit Gateway

The following diagram (Figure 7) shows an example of AWS Cloud WAN deployment in two AWS Regions. With stateful inspection, to maintain symmetry across Regions, we configured routing such that traffic traverses the firewalls in both source and destination Regions.

Figure 7: Centralized VPC-to-VPC inspection with AWS Cloud WAN

Considerations

• There is no additional cost to enable dual-stack AWS Network Firewall endpoints.
• There is no additional cost to use IPv6 in Amazon VPC.
• Check out the reference architectures for more information on Dual stack and IPv6-only design patterns, view Dual Stack and IPv6-only Amazon VPC Reference Architectures.
• For more information on IPv6 VPCs and subnets, view VPCs and subnets now support more sizes for IPv6 CIDRs.
• For general AWS Network Firewall best practices, view AWS Network Firewall Best Practices Guide.
• For more information about IPv6 on AWS, view Get started with IPv6 on AWS – Resources & Content.

Conclusion

IPv6 adoption is increasing every year, and many AWS customers have reasons and requirements for adopting IPv6 in their environments. Ensuring network security through traffic inspection remains a top priority for IPv4-only, dual-stack, and IPv6-only environments. AWS Network Firewall provides the flexibility and capability to inspect both protocol stacks at no additional cost. To learn about additional IPv6 security and monitoring considerations, read the IPv6 section of the whitepaper Best practices for adopting and designing IPv6-based networks on AWS.

An update was made on June 4, 2024: An earlier version of this post omitted the possibility to use DNS64 and NAT64. The post has been updated to describe the usage of DNS64 and NAT64 for internet egress inspection to IPv4-only targets.