1

I am having a bit of trouble fixing this network issue in AWS. Before going into more details, I will start off by this:

  1. I have a Network Load Balancer with a listener 8243

  2. There's a target group attached to that 8243 listener, where the target group port is also 8243

  3. Behind the target group, there's my EC2 instance running an application on 8243.

The EC2 instance has a security group (SG). Currently the target group health-check is failing because I haven't allowed the traffic from NLB to EC2 in the EC2 instance's SG. Therefore this issue is expected.

My problem is, I don't want to add an inbound rule to EC2's SG for the port 8243 where the source range is either public (0.0.0.0/0) or the Subnet IP range. Because I only want the inbound rule of EC2's SG to have 8243 open ONLY for the traffic coming from the NLB. But the problem is, I cannot attach a security group to the NLB as AWS doesn't allow it. This wasn't the problem when I was using an Application Load Balancer as I could reference ALB's SG in the EC2's SG.

Can someone help me fix this issue?

maslick
  • 2,903
  • 3
  • 28
  • 50
Jananath Banuka
  • 2,951
  • 8
  • 57
  • 105

2 Answers2

2

Network Load Balancer works at Layer-4 (Transport layer) of the OSI model. Unlike the ALB, NLB preserves the client side source IP allowing the back-end (webserver running on your EC2 instance on port 8243) to see the IP address of the client (e.g. web-browser).

So, the only option you have is to add an inbound rule for the Security group of your EC2 instance, which allows traffic to port 8243 from 0.0.0.0/0. This is how the NLB works, and it's absolutely normal.

If your main concern is that someone may bypass the NLB and connect to your EC2 instance directly, then they won't be able to do that, since it (EC2) is deployed to a private subnet and doesn't have a public IP address, and hence is not reachable from 0.0.0.0/0. So you are safe here.

Make sure that:

  • Your NLB is deployed to a public subnet of your VPC
  • The target group should have an Instances target type pointing to your EC2 instance
  • Your EC2 instance is deployed into a private subnet. When creating the instance, set Auto-assign Public IP to Disabled - this will assign only a private IP address to your EC2.
  • Don't forget you will need a NAT gateway (recommended) or a NAT instance.

You can see this question, which is similar to yours. Also, this may answer your question as to why the NLB does not require a Security Group (TLDR: potentially it could, but it was decided not to).

Dharman
  • 30,962
  • 25
  • 85
  • 135
maslick
  • 2,903
  • 3
  • 28
  • 50
1

As far as I understand, you can't attach security group with NLB. Instead, you control access using the security groups(s) attached to the EC2 instances.

nothing happened, if your instances are in private subnets, traffic cannot flow directly to them, you specify all traffic is allowed from everywhere, traffic still won't come.

use NLB's private IP address as source IP(ENI attached to it) for an inbound rule on the configuration, is safe as it will not change for the life of the load-balancer.

MrOverflow
  • 407
  • 3
  • 8
  • your advice on adding NLB's private IP address as source IP (from the ENIs attached to it e.g. 3 AZs - 3 ENIs) for an inbound rule on the EC2 SG does **NOT** hold true: it will only allow the healthchecks from NLB to EC2, the actual traffic from the end-user to EC2 will be dropped (remember NLB preserves the client IP, it doesn't do NAT). So the **ONLY** viable option is to allow traffic to port 8243 from *0.0.0.0/0* – maslick Dec 12 '21 at 07:31