Connection to NLB Timing Out

Health checks come from the IP addresses of the load balancer's network interfaces.

Connections from clients to the target servers will appear to come from the original IP address of the client, even when the connection is proxied through an NLB, if the "client IP preservation" option is enabled for the target group.

If the target server behind the load balancer is configured with IP address based restrictions for accessing the target port tcp/1521, you'll need to set the security group to permit not just the NLB's IP addresses but also those of the clients connecting through the NLB. The health checks will work with only the NLB's IPs permitted.

To troubleshoot your connection timeout issue with the Network Load Balancer (NLB) and EC2 instance running Oracle database, here are some steps you can follow:

1. Check NLB configuration:

   • Ensure the NLB is in a public subnet if you're trying to access it from outside the VPC.
   • Verify that the NLB has a public IP address assigned if it's intended to be publicly accessible.

2. Security Group settings:

   • Confirm that the security group associated with the NLB allows inbound traffic on port 1521 from your client IP address or range.
   • Verify that the EC2 instance's security group allows inbound traffic on port 1521 from the NLB's private IP addresses.

3. Network ACLs:

   • Check both inbound and outbound rules of the Network ACLs associated with the NLB and EC2 instance subnets. Ensure they allow traffic on port 1521 and the ephemeral port range (usually 1024-65535) for return traffic.

4. VPC Flow Logs:

   • Enable VPC Flow Logs to trace the traffic path and identify where the connection is being dropped.

5. Route tables:

   • Verify that the route tables for the NLB and EC2 instance subnets are correctly configured to allow traffic between them and to the internet gateway if public access is required.

6. Firewall or security appliances:

   • If you have any third-party firewalls or security appliances in your VPC, ensure they're not blocking the traffic.

7. Client-side firewall:

   • Check if the firewall on your client machine (where you're running PowerShell) is not blocking outbound connections to port 1521.

8. DNS resolution:

   • Ensure that DNS resolution for the NLB's DNS name is working correctly from your client.

9. TCP keepalive:

   • Consider implementing TCP keepalive on both the client and server sides to maintain long-running connections, especially if your application requires extended idle periods.

10. Idle timeout settings:

    • Review and adjust idle timeout settings for the NLB and EC2 instance to ensure they align with your application requirements.

If the issue persists after checking these points, you may need to perform more in-depth network diagnostics or consider engaging AWS support for further assistance.

Remember that while the target group shows as healthy, this only indicates that the NLB can reach the EC2 instance internally. External access still depends on proper configuration of all the network components mentioned above.

Sources
Timeout Issue with Public Network Load Balancer to RDS through AWS VPN Client | AWS re:Post
Resolve Network Load Balancer's TCP connectivity errors | AWS re:Post
Introducing configurable Idle timeout for Connection tracking | Networking & Content Delivery
Resolve HTTP connection errors with Application Load Balancer | AWS re:Post
Troubleshoot connection to AWS service endpoints from Linux | AWS re:Post