What is the best way to implement TwinGate to restrict access to an RDS dB on a private subnet behind a EC2 bastion in AWS?

Support / Troubleshooting
1

Hello we have implemented TwinGate on AWS EC2 Bastion instance, it has worked great for securing access to our public applications urls resident in CloudFront and Fargate servers.

I am have trouble adding RDS Databases on a private subnet to the resources to be protected by the VPN.

Prior to TwinGate we used the EC2 Bastion to only open up SSH to specific IP addresses, who then would use SSH keys to access the RDS resource.

I would like to get rid of the IP whitelist restriction and just allow open IP whitelist 0.0.0.0 on port 22, just like I do for urls behind ports 80/443 on Twingate.

However, TwinGate client connection does not seem to be required to access port 22 and reach the url of this RDS resource.

What is the best way to implement TwinGate to restrict access to an RDS dB on a private subnet behind a EC2 bastion in AWS?

2

Figured it out. The client software for connecting to the dB server was still using SSH Tunneling and bypassing any TwinGate connection. (although not sure why?)

To enable TwinGate to solely regulate the connection to the RDS resource, I had to turn off Bastion access on port 22 and stop using the SSH Tunneling connection in the dB client software.

So I guess my next question is which is more secure?

  1. TwinGate regulating ZTNA through standard connection or…
  2. Open port 22 to 0.0.0.0 and use SSH tunneling or…
  3. Manage whitelisting allowed IPs to port 22
3

Hey Stew,

I know you don’t advertise, but thanks for sharing what you found!

Theoretically, if you have a Twingate connector that can access the RDS server, the only IP you should have to whitelist on the RDS server should be the IP of the Twingate Connector itself ie:

RDS Host: x.x.x.x
Connector: y.y.y.y

If you only allow traffic to the RDS Host via the Twingate connector IP, than the ONLY way you can access that at all is if the user is A) connected to Twingate, and B) given access to the RDS resource within your Twingate access configuration.

They would then just need to be signed in to Twingate, and connect to y.y.y.y, and Twingate does the rest, with absolutely no exposure of your RDS to to the outside world.

The connector would essentially take the place of your bastion host but without any actual tunnelling requirements or anything like that.

Hope this makes sense, let me know if I’m totally off base/misunderstanding your situation!

Thanks,

-arthur

4

Arthur,

Thanks. The RDS whitelist was already setup for the Bastion to route between the public and private subnets.

What was confusing was having SSH Port 22 open on the bastion AND using SSH tunneling bypassed any ZTNA controls TwinGate has in place.

Once I disable Port 22 AND switch OFF the dB client using SSH Tunneling, TwinGate behaved as you describe.