Possible new port restrictions added?

[amhashicorp]

Hi,

I have been using this code to successfully connect to an RDS instance in a private subnet. I was working on adding some extra functionality but then started to hit some errors that did not correlate with the changes I had made.

I decided to go back to trying to use the code in this repo which worked originally and found I could have the connection waiting on a port but then when trying to connect I received the following error:

Error: : dialing websocket: websocket: bad handshake

I decided to go even more basic and ran this command -

aws ec2-instance-connect open-tunnel \
  --private-ip-address <IP-ADDRESS-WAS-HERE> \
  --instance-connect-endpoint-id "<ENDPOINT-ID-WAS-HERE>" \
  --remote-port 5432 \
  --local-port 5432 \
  --region us-west-2

I found I got this output error:

Listening for connections on port 5432.
[1] Accepted new tcp connection, opening websocket tunnel.

awscli.customizations.ec2instanceconnect.websocket - ERROR - {"ErrorCode":"InvalidParameter","Message":"The specified RemotePort is not valid. Specify either 22 or 3389 as the RemotePort and retry your request."}

AWS_ERROR_HTTP_WEBSOCKET_UPGRADE_FAILURE: Failed to upgrade HTTP connection to Websocket.

This error seems to suggest that the RemotePort options has now been restricted to 3389 (RDP) and 22 (SSH)?

Has anyone else experienced this?

[goosefraba]

Since some hours, I have the same issue. Everything worked before and when I select a database now after using rdsconn proxy command and try to connect to localhost:5432 I get the same error message.

[aidansteele]

Yep, I'm seeing this too. It seems that the service is now restricted to standard SSH and RDP ports. I assume that RDS would still work if configured to listen on port 3389 (instead of 5432) but I don't think that's a reasonable thing for me to suggest people do. I'll keep this issue open if people want to subscribe to hear about updates in the future (e.g. if AWS removes the restriction)

[avoidik]

have you added any security group(s) to EICE when you've been creating it?

[goosefraba]

Yes and I also tried to allow all traffic but still not working.

[avoidik]

what a shame, this is an AWS API limitation now, not a network

[tomkins]

Amusingly - this project was included in AWS Week in Review, so at least some people at AWS like the idea of it - even if others have locked it down.

[yevman]

Instead of changing the DB sport is there any simple and cheap AWS service that can be used to switch port traffic before hitting the DB from the EIC?

[aidansteele]

@yevman I'm not sure it meets the "cheap" criteria, but you could use a Network Load Balancer in TCP mode. It could listen on port 3389 and forward to a target listening on a different port (e.g. your RDS instance listening on port 5432)

[MStaniaszek]

@yevman I'm not sure it meets the "cheap" criteria, but you could use a Network Load Balancer in TCP mode. It could listen on port 3389 and forward to a target listening on a different port (e.g. your RDS instance listening on port 5432)

Is it possible to achieve? I tried this approach but it gives me an error Encountered error with websocket: (9, 'Bad file descriptor')

[mathewmoon]

@MStaniaszek When I got that error it was due to a SG rule. The problem with a NLB is that the target IP addresses for the RDS endpoints are subject to change. I've created a solution with a Lambda that runs every minute to check that the target group IP matches the latest result of dig but that's a pretty hacky solution and if you're using IaC you have to either let the Lambda handle creating the target group or, if using Terraform, add a lifecycle.ignore_changes to the resource so your next run doesn't try to "fix" it.

I was however able to just create a cluster running on port 3389. I wouldn't do that in production though. If they updated the ports without warning who's to say they won't do something to limit the protocol that is allowed to pass through it. It peeves me off that such a breaking change, in however short a time from initial release, wouldn't be predicated on a proper deprecation notice.

In the end I would spend the extra 5 minutes to create a nano bastion host for SSM before trying to hack around the breaking change. It's a pity though. I was excited about the service.

[nitrocode]

I guess it's back to a bastion host.

Maybe BohdanPetryshyn/basti (temp bastion host + ssm) can be used while we wait for aws to open up port 5432 again via ec2 instance connect?