Connecting the MySQL Workbench to an RDS Instance via SSH Tunnel

Hi All.

I stumbled into a bit of an error trying to setup the MySQL Workbench to SSH Tunnel to the RDS Instance.  What I had done is missed the fact that new NACLs are created with DENY ALL on both the INBOUND and OUTBOUND rule sets.  Simply adding an ALLOW ALL to the outbound rule set on the new NACL allowed it to work.

Double check all security groups and NACLs if you're having issues.  The problem will be in there somewhere.
  • post-author-pic
    Broadus P

    Thank you for giving students feedback on the lesson, yes make sure the correct ports are open on the NACLs, or you can do ALLOW ALL just for oversimplification! 

  • post-author-pic
    Paolo C

    Hi liamab,

    thanks for the suggestion, I experienced the same issue with NACLs.

    For those who would like to understand the reason why the connection didn't work.

    In my case the follwoing NACL was associated to the Public Subnets:
    Inbound Rules

    100  SSH                   TCP    22   ALLOW
    101    HTTP               TCP    80   ALLOW
    102   HTTPS            TCP    443 ALLOW
    *         ALL Traffic   ALL     ALL DENY
    The NACL associated to the Private (and remaining) Subnets is:
    Inbound Rules

    For both NACLs, Outbound Rules allow all traffic to leave.

    I checked I could access the EC2 instance with Putty via SSH and it worked, meaning to me that the firts NACL was correct.

    However, MySQL Client Workbench couldn't connect.

    The reason behind it is that the RDS Instance would reply to the connection from the EC2 instance using plain TCP and not an SSH connection. Additionally, unless there is a standard and fixed port to be used for outbound traffic from the client to the SQL server, the SQL server could send its replies to any TCP port.

    At the end to have the connection working, an additional rule allowing at least all TCP Inboud traffic allowed has to be added to the NACL:

    A better definition of the above rule is to only permit traffic from the VPC for example or from the private networks.

    Hope this explanation helps.

  • post-author-pic

    Hi paolocandelari. 

    Thanks for reply, I note you opened up all TCP ports on the outbound side.  This could be secured by only allowing the Ephemeral Ports TCP 1024-65535  and specifying only those service ports of which you use, for example, SSH on port 22.   The Ephemeral ports allow the receiving of data .  I would recommend this over opening all ports.

  • post-author-pic
    Paolo C

    Hi  @liamab ,

    thanks for your reply.

    I'm concerned about security and I actually mentioned that in my post, saying that a better inbound rule would be, for example, to allow inbound traffic only from the private subnets.

    That actually is what I did and worked very well.

    The TCP inbound rule I put in my post was just an example to show that the traffic between the EC2 instance and the RDS instance was over TCP but not through port 22 (SSH).

    About ephemeral ports, that is what I did instead for permitting yum to receive the updates from repositories in another exercise I did.

    At the end the message is: check your NACLs!
    In the videos the NACLs were left untouched with all traffic allowed inbound and outbound, but if instead specific NACLs are applied, they may be the reason of lot of pain, as you pointed out in your original post.


  • post-author-pic
    Ilyas G

    Is there a checklist pre-requirements and post re-requirements to for this lab ?  


    Is there a checklist pre-requirements and post re-requirements to for this lab ? if it can  be created, it would be nice. In any case is there a command line test process and check logs to make sense out of the logs. I had the same problem and it is not very clear for a beginner without a checklist to accomplish this. thanks,

Looking For Team Training?

Learn More