Networking & Content Delivery
New – Gateway Load Balancer support for IPv6
In 2020, we launched Gateway Load Balancer (GWLB), allowing you to deploy in-line inspection and filtering of packets. Various customers are leveraging this service to implement firewalls, intrusion detection, and network monitoring appliances in a centralized location. The ability to use multiple GWLB endpoints installed in workload VPCs allows distributed access to these centralized inspection appliances.
At launch, GWLB only supported Internet Protocol version 4 (IPv4) traffic. Today, we are announcing the support of Internet Protocol version 6 (IPv6) for GWLB. GWLB sends IPv6 packets to the target appliances encapsulated in the same IPv4 Generic Network Virtualization Encapsulation (GENEVE) as IPv4, reducing the complexity of enabling IPv6 support. Adding IPv6 allows you to prevent applications from having to downgrade to IPv4, avoid IPv4 address scarcity, and can improve application usability by reducing latency caused by NAT devices. AWS supports IPv6 across multiple services – the Amazon VPC IPv6 page goes into more detail, benefits, and use cases.
In this blog, we will show you how to configure GWLB for handling IPv4 and IPv6 traffic. A previous blog documented how to set up GWLB, and the steps below highlight the changes needed to support IPv6. Before performing the steps below, you need to have the following pieces built:
- Your inspection VPC and subnet that will hold your GWLB must be created and be dual-stacked.
- Your application VPCs and subnets that will hold the GWLB endpoints must be created and dual-stacked.
- You need to have at least one GWLB-aware appliance set up and deployed to be a target – you can use gwlbtun (which has been updated to support IPv6) or any other appliance that has had support for IPv6 added. While your appliances do not need to be dual-stacked themselves at the OS level, they do need to be able to process both IPv4 and IPv6 traffic received from GWLB, which may require them to be dual-stacked depending on use case.
You can create a new GWLB or modify an existing GWLB using either the Console or CLI.
To create a new GWLB using the Console:
Creating a dual-stack GWLB follows the same process as creating a GWLB for IPv4, with a few key settings required to enable the dual-stack mode:
- Go to the EC2 Console, Load Balancers, click ‘Create load balancer’ at the top, and then ‘Create’ under ‘Gateway Load Balancer’. In the configuration, select ‘Dualstack’ as the IP address type:
- Select the target group via the drop down – you can create a target group here as well, if you do not have one already created. Note that targets are reached via IPv4, so Instances and IP addresses are both available for targets. Click ‘Create Load Balancer’ at the bottom of this bage to complete this step.
- Next, go to VPC Endpoint services, and click ‘Create endpoint service’. In the configuration, check both ‘IPv4’ and ‘IPv6’ under ‘Supported IP address types’ in the ‘Additional settings’ section, then click “Create”:
- Create the endpoints in your application VPCs, and select ‘Dualstack’ under Subnets. Note that the subnets need to be dual-stack already, and you will need to create one endpoint per subnet:
- If you left ‘Acceptance Required’ checked on the endpoint service, go back to that endpoint service and accept the connection from the endpoint.
To create a new GWLB using the CLI:
- Create the GWLB, making sure to specify this is a dual-stack load balancer. Replace
subnet-abcdef01234567890
with the space-separated list of dual-stack subnets inside your Inspection VPC. While the subnets must be dual-stack for the GWLB to be created, your appliances (referenced later) do not need to be.aws elbv2 create-load-balancer --name Demo-IPv6-GWLB --subnets subnet-abcdef01234567890 --type gateway --ip-address-type dualstack
- Create the target group. Replace
vpc-abcdef01234567890
with the VPC ID of where your inspection appliances reside:aws elbv2 create-target-group --name Appliances --protocol GENEVE --port 6081 --vpc-id vpc-abcdef01234567890
- Register the firewall appliances with the target group. Replace
arn:aws:elasticloadbalancing:us-west-2:111122223333:targetgroup/Appliances/abcdef01234567890
with theTargetGroupArn
value returned bycreate-target-group
in step 2, andi-abcdef01234567890
with one or more of the instance IDs of your inspection appliances:aws elbv2 register-targets --target-group-arn arn:aws:elasticloadbalancing:us-west-2:111122223333:targetgroup/Appliances/abcdef01234567890 --targets Id=i-abcdef01234567890
- Create the listener. Replace
arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890
with theLoadBalancerArn
value returned bycreate-load-balancer
in step 1, andarn:aws:elasticloadbalancing:us-west-2:111122223333:targetgroup/Appliances/abcdef01234567890
with theTargetGroupArn
value returned bycreate-target-group
in step 2:aws elbv2 create-listener --load-balancer-arn
arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890
--default-actions Type=forward,TargetGroupArn=arn:aws:elasticloadbalancing:us-west-2:111122223333:targetgroup/Appliances/abcdef01234567890
- Create the Endpoint Service, ensuring both IPv4 and IPv6 address types are enabled. Replace
arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890
with theLoadBalancerArn
value returned bycreate-load-balancer
in step 1:aws ec2 create-vpc-endpoint-service-configuration --gateway-load-balancer-arns arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890 --supported-ip-address-types ipv4 ipv6
- Create the endpoints in the application VPCs that connect to the endpoint service just created, again ensuring that the IP address type
dualstack
is selected. You need to create one endpoint per subnet, with separate commands. Replacevpc-abcdef01234567890
with your application’s VPC ID,subnet-abcdef01234567890
with your application’s dual-stack subnet ID, andamazonaws.vpce.us-west-2.vpce-svc-abcdef01234567890
with theServiceName
returned bycreate-vpc-endpoint-service-configuration
in step 5:aws ec2 create-vpc-endpoint --vpc-id vpc-abcdef01234567890 --subnet-ids subnet-abcdef01234567890 --service-name com.amazonaws.vpce.us-west-2.vpce-svc-abcdef01234567890 --vpc-endpoint-type GatewayLoadBalancer --ip-address-type dualstack
- Finally, accept the connection. Replace
vpce-svc-abcdef01234567890
with theServiceId
returned bycreate-vpc-endpoint-service-configuration
in step 5, andvpce-abcdef01234567890
with theVpcEndpointId
returned bycreate-vpc-endpoint
in step 6:aws ec2 accept-vpc-endpoint-connections --service-id vpce-svc-abcdef01234567890 --vpc-endpoint-ids vpce-abcdef01234567890
Note that the ‘accept-vpc-endpoint-connections’ command returns a list of unsuccessful endpoint IDs. The normal response if everything is successful is:
{ "Unsuccessful": [] }
To modify an existing GWLB using the Console:
Before starting, ensure your VPCs and Subnets for both your inspection VPC and application VPCs have had IPv6 address blocks added to them.
- Go to EC2, Load Balancers, select your load balancer, and select ‘Edit IP address’ from ‘Actions’ menu:
- In the ‘Edit IP address type’ screen, select ‘Dualstack’ under ‘Basic configuration’, then click ‘Save changes’ at the bottom:
- Go to VPC, Endpoint services, select your endpoint service, and under ‘Actions’, select ‘Modify supported IP address types’:
- In the ‘Modify supported IP address types’ screen, ensure both IPv4 and IPv6 are checked under ‘Supported IP address types’, then click ‘Save changes’:
- For each endpoint deployed, go to VPC, Endpoints, select the endpoint, and select ‘Modify endpoint settings’. Note that this action is only available on endpoints that have been accepted by the Endpoint Service – otherwise the option will be unavailable:
- Finally, under ‘Modify IP address type settings’, select ‘Dualstack’, and click ‘Save changes’:
To modify an existing GWLB using the CLI:
Before starting, ensure your VPCs and Subnets for both your inspection VPC and application VPCs have IPv6 address blocks added to them.
- Change the address type of the GWLB to dualstack. Replace
arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890
with the ARN of your existing GWLB:aws elbv2 set-ip-address-type --load-balancer-arn arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890 --ip-address-type dualstack
- Modify the endpoint service to add IPv6 as a supported IP address type. Replace
vpce-svc-abcdef01234567890
with the VPC endpoint service’s service ID:aws ec2 modify-vpc-endpoint-service-configuration --service-id vpce-svc-abcdef01234567890 --add-supported-ip-address-types ipv6
- Update each endpoint referencing your endpoint service to enable dualstack mode. Replace
vpce-abcdef01234567890
with the VPC endpoint’s ID:aws ec2 modify-vpc-endpoint --vpc-endpoint-id vpce-abcdef01234567890 --ip-address-type dualstack
Verifying configuration using the Console:
To verify configuration using the Console, perform the following steps:
- Go to EC2, Load balancers, select your GWLB, and ensure ‘IP address type’ shows ‘Dualstack’:
- Go to VPC, Endpoint services, select your endpoint service, and ensure that ‘Supported IP address type’ shows 2 entries – you can mouse over the ‘2’ and should see ‘ipv4’ and ‘ipv6’ listed:
- Go to VPC, Endpoints, and under the Subnets, verify ‘IP address type’ is ‘dualstack’, and both an IPv4 address and an IPv6 address have been assigned:
Verifying configuration using the CLI:
To verify configuration using the CLI, perform the following steps.
- Verify the GWLB is shows an
IpAddressType
ofdualstack
. Replacearn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890
with the ARN of your GWLB:aws elbv2 describe-load-balancers --load-balancer-arn arn:aws:elasticloadbalancing:us-west-2:111122223333:loadbalancer/gwy/Demo-IPv6-GWLB/abcdef01234567890 --query 'LoadBalancers[*].IpAddressType' [ "dualstack" ]
- Verify the endpoint service shows both
ipv4
andipv6
underSupportedIpAddressTypes
. Replacevpce-svc-abcdef01234567890
with your endpoint service ID:aws ec2 describe-vpc-endpoint-service-configurations --service-id vpce-svc-abcdef01234567890 --query 'ServiceConfigurations[*].SupportedIpAddressTypes' [ [ "ipv4", "ipv6" ] ]
- Verify the endpoint shows an
IpAddressType
of dualstack. Replacevpce-abcdef01234567890
with your VPC Endpoint ID:aws ec2 describe-vpc-endpoints --vpc-endpoint-id vpce-abcdef01234567890 --query 'VpcEndpoints[*].IpAddressType' [ "dualstack" ]
After you have completed the above steps, update your application subnet route tables to send both IPv4 and IPv6 traffic to the endpoint as per your requirements. An example one-arm (see this blog for a description of one-arm versus two-arm mode) appliance configuration could look like this:
Things to Know
Some key things to keep in mind:
- In one-arm mode, we recommend bypassing NAT Gateway for IPv6 traffic (which would perform a NAT64), and instead go directly to an Internet Gateway (IGW)
- In two-arm mode, you should perform the same operations on IPv6 traffic as you are IPv4. Specifically, your appliance will need to do NAT66 (IPv6 to IPv6) on the IPv6 traffic, as the appliance’s VPC’s IGW will only accept traffic from the local subnet ranges.
- If creating the Endpoints in a different account than the Endpoint Service, the Endpoint Service needs to have the account added to the Allow Principals, otherwise the Console will not accept the Endpoint Service name:
Things to Know as an Appliance Creator
If you are building or updating your own appliance, there are a few things to keep in mind while updating it to support IPv6:
- As mentioned above, GWLB wraps the payload in GENEVE, using IPv4 as the outer layer, regardless if the payload inside is IPv4 or IPv6. Thus, the information in this blog post on how to process the traffic and send it back to GWLB remains valid for IPv6 payloads. That blog post also discusses the Flow Cookie, mentioned below.
- Inside the GENEVE encapsulation, IPv4 packets continue to use an EtherType of
0x0800
, denoting a layer 3 IPv4 packet. IPv6 packets use their corresponding EtherType of0x86dd
. This is how you can tell the difference between the two different types of traffic coming in. - GWLB adds a “Flow Cookie” in a option value inside the GENEVE headers, and an application must return the same headers (including matching Flow Cookie) when sending traffic back to GWLB. For Flow Cookie calculations, a ‘flow’ is a given source IP/destination IP pair, with corresponding source/destination port pair, and protocol, for both IPv4 and IPv6. This means that appliances must track different Flow Cookies per flow, and the Flow Cookie is the same for both directions of a given flow.
Availability and Pricing – IPv6 support for Gateway Load Balancer is now available in all regions where GWLB is supported. There is no additional charge to enable IPv6 support for a load balancer, and standard charges apply for all traffic regardless of being IPv4 or IPv6.
Enabling your Gateway Load Balancers and appliances for IPv6 will allow your appliances to inspect and monitor the IPv6 traffic going through your network, using the same technology you already use for IPv4. IPv6 usage is growing on the Internet, and allowing your applications to directly work over IPv6, with the security and inspection provided by GWLB appliances, avoids needing to use NAT and overlapping IP address blocks, while unblocking direct IPv6 to IPv6 communication. Start today by enabling this feature in your test environments.