How to test IPv4 of Internal ALB (dualstack)

To address your questions about testing IPv4 connectivity for a dualstack internal Application Load Balancer (ALB):

1. Identifying internal IPv4 addresses of an ALB: The recommended way to test connectivity to an internal ALB is not by using its IP addresses directly, but rather by using its DNS name. You can perform a simple telnet or netcat test like:

telnet <ALB DNS name> <ALB listener port>

If you need to specifically identify the IPv4 addresses, you can use DNS lookup tools like nslookup or dig against the ALB's DNS name. For example:

nslookup <ALB DNS name>

or

dig <ALB DNS name> A +short

However, it's important to note that directly accessing an ALB via its IP addresses is not recommended because these IPs can change over time as AWS scales or maintains the ALB.

2. Troubleshooting GlobalAccelerator access to the IPv4 half of a dualstack internal ALB: The "400 Bad Request" error when accessing the ALB directly via its IP address is expected behavior. ALBs require the Host header to be set correctly, which happens automatically when you use the DNS name.

For troubleshooting the GlobalAccelerator to internal ALB connectivity:

• Verify that the GlobalAccelerator is properly configured to point to your ALB
• Check that the security groups for your ALB allow traffic from the GlobalAccelerator
• Ensure that network ACLs in your VPC allow the necessary traffic
• Confirm that your internal ALB is properly configured as dualstack
• Test connectivity from within your VPC using the ALB's DNS name rather than direct IP addresses

The fact that adding the IP to your /etc/hosts file makes it work suggests that the issue might be related to DNS resolution or Host header handling. When you use the DNS name (even if it resolves to the IP via your hosts file), the proper Host header is sent with the request.
Sources
Resolve HTTP connection errors with Application Load Balancer | AWS re:Post
Introducing dual-stack without public IPv4 Application Load Balancer | Networking & Content Delivery

A general best practice is to configure the listener rules on your ALB only to forward requests containing a valid "Host" header to targets. This usually prevents a large number of casual, IP-based reconnaissance scans and probes from reaching your backend services.

I don't know how your listener rules are set up, but since you're mentioning that requests are successful when accessing the ALB internally with the correct DNS name resolved via /etc/hosts, the symptom would match the best-practice configuration of an ALB. The first listener rules would send requests with the expected Host header to the backend resources, and the default listener rule would return a fixed response with a 400, 404, 500, or similar error code.

Another clear possibility would be that equivalent Host header based filtering/routing could be done by the backend resource, and it could be returning the 400 response to requests made without the correct hostname.

If you want requests from inside the VPC to access the ALB directly, without taking an external round-trip via Global Accelerator, one option would be to configure a Route 53 private hosted zone (PHZ) for the hostname(s) of your ALB, create A and/or AAAA alias records in the PHZ pointing to the DNS name of the internal ALB, and associate the PHZ with your VPC. If your ALB's public DNS name is "www.example.com", the name would point to the Global Accelerator endpoint in your public DNS zone but to the internal ALB by the PHZ entry associated with your VPC.

Note that this approach may not be convenient for redirecting the apex record of a zone heavily used for purposes other than the ALB. If "example.com" is a large public zone for your company, as an example, creating a PHZ for the whole "example.com" namespace would prevent all the other names under the zone from being resolved from inside your VPC. In that case, it's best to make the calls from within the VPC with a name other than the apex record and create the PHZ only for that single name, such as "www.example.com" or "api.example.com".