0

I've recently started the process of switching from AWS ELB to NLB, and I'm facing some connectivity issues.

We have 2 VPCs. In VPC1, both EC2 database servers, old ELB and NLB is located. In VPC2, we have some EC2 servers that connect to the database servers

In VPC1, we face no connectivity issues.

In VPC2, I can't reach the DB via the NLB.

  • I can reach the DB via the old ELB, which is in the same sec group as the EC2 server
  • I can reach the DB via direct connection to the DB server (The EC2 DB server allows traffic from VPC2)
  • The NLB, ELB and the EC2 DB server are in the same subnet
  • The NLB is of the internal type

From what I understand with regards to how NLB works, just the fact that I can connect directly to the EC2 instance means that I should be able to connect to it via NLB - the NLB has no security group of itself and uses the sec group of the EC2 instance, since it forwards the source IP.

Does anyone have any ideas about what could be wrong?

Simon Fredsted
  • 154
  • 10
  • Why do you want NLB in front of the DB? That doesn’t sound right. Can you update the question with more details of *why* are you doing that? – MLu Feb 18 '19 at 11:35
  • @MLu The NLB is in front of an Elasticsearch cluster, which we often scale up or down. – Simon Fredsted Feb 18 '19 at 12:03
  • I still don't get it. You say "*In VPC2, I can't reach the DB via the NLB.*" - why would you want to reach DB via NLB? The App should talk to the DB directly, using its DNS name. The NLB should only talk to the ElasticSearch nodes. – MLu Feb 18 '19 at 20:26
  • Here's a diagram: app → NLB → ES cluster (doesn't work), app → ES node (works) , app → ELB → ES cluster (works) – Simon Fredsted Feb 19 '19 at 08:37

3 Answers3

0

If the NLB is of internal type it means that it has no public ip. To be able to route traffic to it from another VPC over ther NLB's private IP there needs to be a VPC-peering between those VPCs in place. For the VPC peering to work you will also need to add routes for the peering connection to the route table of your subnet(s)

Henrik Pingel
  • 9,380
  • 2
  • 28
  • 39
  • Hi Henrik, a Peering Connection is already set up: all the connections described above (e.g. from VPC2 to ELB or EC2 DB server) happen on a private network. – Simon Fredsted Feb 18 '19 at 12:29
  • Did you check that there is a route in VPC2 for the CIDR range of VPC1 pointing to the peering connection. – Henrik Pingel Feb 18 '19 at 16:23
  • Yep, the peering connection and its routes are set up correctly. There's a lot of communication between the two VPCs, and there's only a problem when connecting through the NLB. – Simon Fredsted Feb 19 '19 at 08:39
0

the NLB has no security group of itself and uses the sec group of the EC2 instance, since it forwards the source IP.

That's not correct. NLB has no security group but it also hides the security group of the source. It simply works with IP addresses.

So if your DB security group permits access from the EC2 SG you will have to add another rule, IP-based, to permit access from the client IPs. As soon as the traffic passes through NLB it loses its source security group label.

Anyway NLB is for quite specialised use cases. Are you sure you wouldn't be better served with ALB (Application Load Balancer)? It works on HTTP / HTTPS level and gives you more control over the request routing, etc.

Hope that helps :)

MLu
  • 24,849
  • 5
  • 59
  • 86
  • mlu, thanks for your time. The rules in the VPC1 security group are already IP-based, since you can't reference security groups from other VPCs. – Simon Fredsted Feb 19 '19 at 08:49
0

Turns out that while NLB supports VPC peering, it only works with so-called Nitro instances:

If the peered VPC is in the same region as the load balancer, the clients must be Nitro instances.

The instances in "VPC2" are of type t2.small, which are not Nitro.

Simon Fredsted
  • 154
  • 10