2

Ec2 SQL Database server:

Connection-specific DNS Suffix  . : ec2.internal
Link-local IPv6 Address . . . . . : fe80::9ca:e9d1:a7b5:3e42%16
IPv4 Address. . . . . . . . . . . : 172.31.21.189
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.31.16.1

*(Please note that this Ec2 DB currently also has a publicly accessible elastic ip associated with it. I'm noting this because in the VPC peering docs I saw that VPC peering will not function correctly if there is a public IP associated with it)

I setup a AWS Workspace Directory on the same VPC, Workspace Client networking:

Connection-specific DNS Suffix  . : ec2.internal
Link-local IPv6 Address . . . . . : fe80::dc3c:d1c1:c7fe:812b%15
IPv4 Address. . . . . . . . . . . : 172.31.16.45
Subnet Mask . . . . . . . . . . . : 255.255.240.0
Default Gateway . . . . . . . . . : 172.31.16.1

While these are on the same CIDR 172.31 they're unable to communicate, I read the documentation on VPC peering but I don't think it's applicable in this situation. What is the appropriate and secure way to setup network connectivity between the workspace desktop's (client app) and the sql database on my ec2 instance.

Edit

1) I have added the following rule in the EC2 security group to allow traffic to the DB server: enter image description here 2) Have disabled windows firewall on both boxes.

bumble_bee_tuna
  • 443
  • 11
  • 26
  • 1
    That security group won't work. the /32 bitmask you included is specifying just one ip address, not a range. Try 172.31.16.0/20 (or whatever you actually used when creating the 172.31.16.0 subnet.) You could also do 172.31.0.0/16 to allow anything within the VPC to reach the SQL Server, if that meets your requirements. If you really only want to allow the one desktop to reach the sql server, then try 172.31.16.45/32 – vjones Jul 26 '19 at 21:49

1 Answers1

1

I'd suspect an issue in one of the following areas:

  1. An issue with security groups. If both instances have the default security group, there should not be a problem, but you may have created a new security group for your SQL instance (since it has an external IP address.) If so, you need to make sure you allow access from the security group, ip addres, or ip address range of the workspace cilent.
  2. An issue with routing tables (unlikely, unless you've modified the default)
  3. A firewall issue (for example, if the EC2 SQL instance is SQL Server running on Windows, there may be a windows firewall enabled on the instance)
  4. An issue with NACLs (Again, probably not an issue, unless you've modified them.)

You're right that vpc peering is not the solution. vpc peering allows you to route between two different vpcs. You have two subnets in the same VPC, so this is not what you need.

Some example security rules that should work:

  • 172.31.0.0/16 - allow anything in the VPC to access the SQL Server
  • 172.31.16.0/20 -allow anything in the 172.31.16.0 subnet to access the SQL Server
  • 172.31.16.45/32 - allow the one desktop to access the SQL server.

(In case it isn't clear, you should add these to the security group associated with the SQL Server. )

vjones
  • 851
  • 7
  • 13
  • Please see my edit I added a rule for that .16 CIDR but still don't have connectivity. Also don't have windows firewall enabled on either side. Any other ideas ? – bumble_bee_tuna Jul 26 '19 at 18:15