Timeout Issue with Public Network Load Balancer to RDS through AWS VPN Client

0

I'm facing a connection timeout issue in my AWS setup and need some help troubleshooting it. Here’s the current configuration: I have a public Network Load Balancer (NLB) set up to connect to an RDS instance. Access to the NLB is restricted by allowing only my office IP. Employees working from home connect to the VPC using an AWS VPN client. The VPN client is configured in the same subnet where the NLB is located, which is a public subnet. I've set up the security groups to allow traffic from the VPN client’s security group to the NLB’s security group on the RDS port.

Despite this setup, users are experiencing connection timeouts when trying to access the RDS instance through the NLB while connected via the VPN.

3 Answers
0

Hello.

I think that the connection from AWS ClientVPN to the public NLB will use a public IP address even if it is within the same VPC.
Therefore, AWS ClientVPN must be able to access the NLB via a public IP address, such as via a NAT Gateway.
Also, the NLB security group must allow the NAT Gateway's public IP address.
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/using-aws-client-vpn-to-scale-your-work-from-home-capacity/

By the way, why are you using NLB to connect to RDS?
If you are using AWS ClientVPN, you can connect to RDS directly without going through NLB.

profile picture
EXPERT
answered a month ago
  • Thanks for your answer. The reason I am using an NLB to connect to RDS is that it's not suitable for my team to work all day connected through a VPN. The NLB allows our office to have a more stable and direct connection to the private RDS instance without the need for a VPN.For employees working from home, they do need to use the VPN. This is because I don't want to expose the NLB to the entire internet by opening it up to 0.0.0.0/0. Instead, the NLB is configured to only allow traffic from our office IP. The VPN provides a secure way for remote workers to access the RDS instance through the NLB without compromising security.

  • I understand your background. In that case, I think users using AWS ClientVPN should connect to RDS via ClientVPN instead of NLB. If you are connecting from the office, I think you should use NLB, but if you use ClientVPN, it is possible to connect without going through NLB. I think the following blog is close to the scenario. https://aws.amazon.com/jp/blogs/database/accessing-an-amazon-rds-instance-remotely-using-aws-client-vpn/

0

It isn't generally advisable to have RDS databases open to the internet, but if it's acceptable in your case, the proper way to do it is to enable the "publicly accessible" option for the RDS database and to configure the security group of the database to allow access only from permitted public IP addresses.

The NLB is a bad solution for a number of reasons, but among the most important, the connections should be TLS-encrypted, and the NLB's DNS name won't match that of the RDS database, so the certificate coming through from the RDS database won't match the name to which users would be connecting. When you make the RDS database publicly accessible, users from your office can connect to it directly with its genuine name. Route 53 Resolver automatically takes care of mapping the name of the database to its internal IP addresses when queried from within the VPC, such as via AWS Client VPN, while returning the public IPs when queried from the outside world, such as from the office.

More details are explained in this documentation section: https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_VPC.WorkingWithRDSInstanceinaVPC.html#USER_VPC.Hiding

EXPERT
answered a month ago
  • Thanks for your answer, but I decided to use a Network Load Balancer because I don't want to enable 'publicly accessible' for my RDS. I configured the NLB with the open IP of my office, and I don't use a VPN from the office.

  • The publicly accessible option does the exact same thing as what you've configured with the NLB, but with less security due to the mismatching TLS certificate. The choice is yours, of course, but I'd just like to clarify that there's no actual security difference between a VPC security group restricting access to the NLB compared to the VPC security group controlling access to the RDS database.

0

Based on the information provided, there are a few potential issues that could be causing the connection timeout when users try to access the RDS instance through the Network Load Balancer (NLB) while connected via the AWS VPN client. Here are some troubleshooting steps and considerations:

  1. VPN Client Configuration: Ensure that the AWS Client VPN endpoint is correctly configured to allow traffic to the NLB and RDS instance. Check if the Client VPN endpoint's associated route table includes a route to the subnet where the NLB is located.

  2. Network ACLs: Verify that the Network Access Control Lists (NACLs) for the subnet where the NLB is located allow inbound and outbound traffic on the necessary ports for both the VPN connection and the RDS instance.

  3. Security Group Configuration: Double-check the security group settings. While you've mentioned allowing traffic from the VPN client's security group to the NLB's security group, ensure that:

    • The NLB's security group allows inbound traffic from the VPN client's CIDR range.
    • The RDS instance's security group allows inbound traffic from the NLB's security group.
  4. DNS Resolution: Confirm that DNS resolution is working correctly for VPN clients. The VPN clients should be able to resolve the NLB's DNS name.

  5. MTU Size: There might be an issue with the Maximum Transmission Unit (MTU) size. Try adjusting the MTU size in the Client VPN configuration. You can add the following line to the Client VPN endpoint's .ovpn configuration file: mssfix 1328

  6. Routing: Ensure that the route tables in the VPC are correctly configured to route traffic from the VPN clients to the NLB and then to the RDS instance.

  7. NLB Target Group: Verify that the NLB's target group has the RDS instance correctly registered and that the health checks are passing.

  8. VPN Client Firewall: Check if the firewall on the users' computers is not blocking the connection. Ensure that it allows outbound traffic on the necessary ports (typically 443 or 1194 for the VPN connection, and the RDS port).

  9. Split Tunneling: If split tunneling is enabled on the VPN client, make sure it's configured correctly to route traffic intended for AWS resources through the VPN connection.

To further diagnose the issue, you can use VPC Flow Logs to trace the traffic path and identify where the connection is failing. Additionally, packet capture tools like Wireshark can be useful to analyze the traffic at different points in the network path.

If the issue persists after checking these points, you may need to engage AWS support for more in-depth troubleshooting, as there could be complex networking issues at play.
Sources
Troubleshooting AWS Client VPN - AWS Client VPN
Troubleshoot Gateway Load Balancer's connectivity issues | AWS re:Post
Troubleshooting common AWS Client VPN problems - AWS Client VPN
Troubleshooting AWS Client VPN: Clients can't access a peered VPC, Amazon S3, or the internet - AWS Client VPN

profile picture
answered a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions