Local Database Client, Private RDS: Why the Connection Times Out

A developer's laptop times out connecting to the private RDS endpoint, while the same credentials work from a bastion host. Nothing is down. The path between that laptop and the database is missing one of three things: a name that resolves, a route that carries the traffic, or a security-group rule that admits the source the database actually sees. Find which one is missing before changing the other two.

Read the failure at the right layer

A timeout is not one error. A name that does not resolve fails before a packet leaves the machine. An unroutable address sends packets into a black hole. A filtered port produces a wait that looks exactly like a wrong host. Run the steps in order and stop at the first one that fails.

dig +short db.internal.example
nc -vz db.internal.example 5432

If the name returns a public address, or returns nothing, the tunnel is not the problem yet.

If the name resolves and the port test hangs, compare the address you resolved with the address the database reports. A managed endpoint can resolve to a private address inside the VPC and to nothing useful outside it, and an address copied from an old lookup will point at a host that no longer answers.

Separate the tunnel from the route

Connecting a client VPN does not automatically route every private range. The profile carries the routes the service pushes, and the client may install only some of them. Look at which ranges the client actually added and whether the database address falls inside one.

ip route get 10.20.40.15
ip addr show tun0

A route that points at the tunnel interface is necessary; it is not sufficient, because the far side still has to accept the traffic.

Split-tunnel profiles are the usual source of this half-failure. They work for the application the profile was designed for and leave the database range outside the tunnel, which produces exactly the timeout a firewall would produce.

Match the security group to the real source

The RDS security group admits sources, not people. Depending on the architecture, the source may be the VPN client pool, the private address of a bastion, or a NAT address the traffic is translated to. Read the rule and the actual packet source together.

aws ec2 describe-security-groups --group-ids sg-0123456789abcdef0 \
  --query 'SecurityGroups[].IpPermissions'

A rule for one laptop's home address is a maintenance problem rather than an access design.

When a client VPN or a NAT gateway sits in the path, the database may see the translator's address instead of the developer's tunnel address. That is why a rule copied from a working bastion setup can fail for a laptop: the two paths arrive from different sources even though both look internal.

Prefer a narrow path to a wide one

When one developer needs one database, session-based forwarding is often cheaper to operate than a full network tunnel. The local client connects to a forwarded port, and the remote component makes the database connection from inside the network.

ssh -N -L 5432:db.internal.example:5432 bastion.internal.example

Keep TLS verification intact in that design. The client should still validate the server certificate against the name it expects; a local forwarded port is not a reason to disable verification, and disabling it hides exactly the identity problem worth catching.

The choice between a full tunnel and a narrow forward is a decision about scope, not about security theater.

Leave a repeatable path behind

Document the endpoint name rather than a resolved address, the source range the security group admits, and the database role the developer uses. Those three facts explain most future failures without a call. Add the client profile version as well, because a profile change can remove a route the old one carried.

Then test the negative case once: a client outside the approved source should still be refused.

A private database that works only for the person who set it up is not private access; it is an undocumented exception waiting to be rediscovered. Write the path down, and the next developer inherits a method instead of a mystery.