I used the migration wizard to create a Network Load balanacer. And I noticed that there are no security groups associated with the NLB like there are for classic and application load balancers. So I checked the NLB name in network interfaces to capture the IP addresses and add them the security group for the instances associated with the target group as:
Custom TCP | TCP | 7443 | IP Address
All of the health checks are still failing however. I was just wondering if anybody has some advice on how to set up NLBs?
Thanks in advance!
A recommended way is to allow entire VPC CIDR range in your instance's security group.
If you don't want to do this, then you have to use private IP address of the NLB nodes. In the above link with recommendation there is procedure listed how to get these IPs.
Related
2 questions on NLB in AWS
I have a requirement to use NLB in front of the EC2 which runs MYSQL. This EC2 is in private network. I just want to allow NLB to be accessed by some particular internet IP. If it's ALB, I can use security group to do this. However, without security group in NLB, how can I achieve this?
In this setup, I connect to NLB from my PC and reach to that MYSQL EC2. To make it success, I find that I have to allow 0.0.0.0/0 in the incoming rule of the EC2 security group instead of just putting my PC IP. I thought my PC IP should be brought to EC2 directly through NLB. Is it not true? I dont want to allow 0.0.0.0/0 in EC2 security group. Is there any better way?
Thanks!
The security group evaluations are performed by the instances security groups for the Network Load Balancer. You would need to add the IP addresses you would like to communicate with the NLB to your instances, as long as your instance is in a private subnet this will prevent any client directly interacting with the host.
Network Load Balancers do not have associated security groups. Therefore, the security groups for your targets must use IP addresses to allow traffic from the load balancer.
More information is available in the Register targets with your target group documentation.
The only way to block the traffic in your case is to have the IPs to which you want to allow access in the EC2 SG.
However you need to account for the fact that there is a difference on the IP address from which the request will come from and thus will be evaluated from the EC2 SG based on how you have configured the target group of the NLB and more specifically on whether you have set up the target type to be instance or ip, as there is a difference in the NLB behaviour.
If the target type is set to instance, the NLB will pass the traffic to your instance as is, and the EC2 SG will see your locap PC public IP address, and if there is a rule to allow it you will be able to connect
If the target type is set to ip, the NLB is doing an NAT, and the EC2 SG will actually see the private IP of the NLB as a source IP for the incoming traffic.
Take a look at the Source IP Preservation in the NLB Target Group documentation.
There is a similar discussion in this question.
I have a service running on the port 8080 of an EC2 machine in a private subnet. My plan is to establish a VpcLink to the private endpoint using a Network load balancer. Now the network load balancer cannot associate a security group of its own, instead the target security group will come into action here (in this case the security group of the EC2 where my service is running). I am a little confused over how does the security group of the ec2 machine looks like. I need to add a custom TCP rule which will allow traffic to port 8080, but I am confused over what IP range I can give in the source. The API gateway has no IP. Also, it is saying that
Recommended Rules
Inbound Source Port Range Comment
Client IP addresses instance listener Allow traffic from clients on the instance listener port
VPC CIDR health check Allow traffic from the load balancer on the health check port
Based on the comments and from the docs:
Network Load Balancers do not have associated security groups. Therefore, the security groups for your targets must use IP addresses to allow traffic from the load balancer.
If you register targets by IP address and do not want to grant access to the entire VPC CIDR, you can grant access to the private IP addresses used by the load balancer nodes.
Thus, for NLB you either use CIDR range of the subnet where NLB is. Or to be more restrictive you using NLB private addresses. For the IP addresses, you can't get them from CloudFormation. Would have to write custom resources in the CloudFormation to get the IPs from NLB. As a compromise, you could put your NLB in a dedicated subnet, or the same one as instances, and used its CIDR range.
I am trying to achieve the following architecture depicted in this blog
I have a Fargate Service using an ENI (with private IP of 10.0.241.85) running in a private subnet (let's call 'subnet-1'). The ENI also has an Elastic IP as it fails to pull the image from ECR if not. I don't think this will matter though? The container in my service is exposing ports 3000/4000. I then have my ALB & NAT gateway in a public subnet (let's call this 'subnet-2'). The ALB forwards traffic on ports 80/443 to the necessary target group. The target group has 2 registered tasks targeting the private IP on the ENI (1 on port 3000 & the other on 4000). To the best of my knowledge, this should allow traffic in, correct?
For traffic out, subnet-1 has a default route (0.0.0.0/0) to the NAT gateway in subnet-2, this should allow traffic out, correct?
All services are in the same VPC & the same availability zone (where applicable)
I have 2 security groups utilised by these services:
test
api
test (inbound)
test (outbound)
api (inbound)
api (outbound)
We leverage ephemeral ports for communication between the 2 security groups
NOTE: I removed the destination here but, yeah, the destination is test security group
| Service | Security Groups |
|---------|-----------------|
| ENI | test |
| | api |
|---------|-----------------|
| ALB | api |
|---------|-----------------|
subnet-1 route table
subnet-2 route table
NOTE: The covered route is just a peering connection out so nothing to do with this
From what I know, the 2 subnets should be able to communicate using the private IPs of the services within them which is what I have done here.
The health check fails with the generic message of:
Task failed ELB health checks
I have also looked to this blog for a bit more help but to no avail.
Any help would be greatly appreciated :)
If your task is listening on ports 3000 & 4000, your security group (test I guess, based on your comments) will need to permit these ports. As configured now, I don't see ports 3000 and 4000 as allowed.
Couple of other notes - an elastic IP on your ENI in a private subnet won't do anything as private subnets cannot have direct access to the internet. If you're having problems connecting to ECR without it there must be some other problem.
Also, your SG rules are permitting very large CIDR blocks like 0.0.0.0/0. A more secure configuration would only permit the particular security group that needs access. In this case, you would want the ports for your app (sounds like 3000 and 4000) from the SG ID of your load balancer.
I have some issue with my ELB.
We are develop some web app and we need to close public access to our app from internet. So about test environment:
example.com -> Application load balancer with route53 -> EC2 in private subnet.
In security group for testing i have opened 0.0.0.0/0 for 80 and 443 (port doesn't matter). My app response and everything works fine.
But i don't need 0.0.0.0/0, so i have changed it to my office IP.
And my app stop working, because IP from Load balancer in 2 availability zones are not allowed in security group of load balancer. It's very strange.. This IP is not static and i have no guaranties that this IP don't change in 5 min. So, what we have, I ALB doesn't allow his traffic via his IP?
The EC2 instances do not need to be in the same security group as the load balancer. The load balancer should be in a security group that permits ports 80/443 from the Internet (or your office IP). The EC2 instances should be in a security group that permits traffic from the load balancer’s security group.
Hm, the reason was that NAT IP with IPs ELB cant access to ALB. Added IP ELB and NAT gateway to secutiry group. Fixed. Thanks for help
If you don't want your application to be open to the public Internet, you can set up a VPN in your VPC or you can use SSH port forwarding to access your application in the private subnet. The linked articles are just examples - there are many ways to do it - but both are common approaches. If you choose either of these options, your ALB does not need to be in a public subnet. It can also be in a private subnet since your application doesn't need to be publicly accessible.
These are the most secure and robust options available to you. Alternatively, if you can determine the IP address range which your ISP assigns, you could open a wider network in your ALB security group but still not allow the full internet. E.g. if your ISP always assigns an address in the range of 1.2.3.0-254, you could add a rule to allow 1.2.3.0/24. Of course anyone else using your ISP that is assigned one of these addresses would also be able to access your application. Alternatively, you could develop a script that keeps updating your ALB security group with a new dynamic address.
Has someone configured a NLB in the public subnets of your VPC to route traffic to EC2 instances that are in the private subnets?
When using an ELB, a good solution is to create a Security Group for the ELB and then create another SecurityGroup for the private EC2 Instances, allowing incoming traffic from that ELB Security Group, as explained here:
https://aws.amazon.com/premiumsupport/knowledge-center/public-load-balancer-private-ec2/
"You can also add a rule on the instance’s security group to allow traffic from the security group assigned to the load balancer. For example, if the security group on the load balancer is sg-1234567a, make the following changes on the security group associated with the private instances"
Since you cannot associate a Security Group to a NLB, how could you accomplish this with the same type of security?
Thanks!
Since you cannot associate a Security Group to a NLB, how could you
accomplish this with the same type of security?
The security aspect does not change.
NLB is a different beast, it not the same as classic Load Balancers. For Classic Load Balancers, from the point of view of your instances, traffic does appear to come from inside the VPC. From outside, traffic goes to a (random and mutating) list of IP addresses, resolved by the DNS record that AWS provides to you.
Network Load Balancers are completely different. From the point of view of your instances, they are completely invisible. If it is an external network load balancer, traffic appears to be coming from instances on the internet directly (even though this is an illusion). Therefore, if you want to talk to everyone on the internet, 0.0.0.0/0 is what you open it to.
This is, in fact, what the documentation says:
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/target-group-register-targets.html#target-security-groups
Recommended Rules
Inbound Source Port Range Comment
Client IP addresses instance listener Allow traffic from clients on the instance listener port
VPC CIDR health check Allow traffic from the load balancer on the health check port
Client IP addresses is whatever your client IPs are. If they are on the open internet, 0.0.0.0/0 it is. Adding the NLB private IP address, as I saw in other responses, accomplishes nothing. Traffic is not coming from there, as far as the instances are concerned.
On the security angle, nothing changes. Since your instances are in private subnets, traffic cannot flow directly to them, as there is a NAT gateway in the middle. It can only flow from them to the internet (through NAT gateway, then internet gateway). Even if you specify all traffic is allowed from everywhere, traffic still won't come. It will have to come through another way. In your case, that way is the NLB, which has a fixed number of ports it listens to, and only sends traffic to the destination ports on the instances you specify.
If you are moving from classic Load Balancers to NLBs, move the security group rules from the Load Balancer to your instances. Or better yet, since you can have multiple security groups, just add the SG you currently have for the classic LB to the instances(and update any ASGs as needed). Your security posture will be exactly the same. With the added benefit that now your applications won't need things like proxy protocol to figure out where traffic is coming from, it is no longer obfuscated by the load balancer.
That is indeed true as per AWS Documentation :
Network Load Balancers do not have associated security groups.
Therefore, the security groups for your targets must use IP addresses
to allow traffic from the load balancer.
So If you do not want to grant access to the entire VPC CIDR, you can grant access to the private IP addresses used by the load balancer nodes. There is one IP address per load balancer subnet.
On NLB Tab of there is one Network Interface per Load Balancer from there :
On the Details tab for each network interface, copy the address from
Primary private IPv4 IP.
You can use this private IP Address at add it SG of EC2 Instances.
Please Refer to AWS Documentation
Tail your http access logs and you will see there is no changing of source IP address from the network load balancer which means you need to allow 0.0.0.0/0 on the endpoints security group if the internet needs access to your endpoint.
This is only ok if you use a private subnet so be careful if you have this server on a public subnet as this solution would not be advisable. In this case just use an application load balancer. You can still setup the same listener and configure a target group by instance as well. The application load balancer will update the source IP address to it's own private address if you tail the access logs. The advantage of this is you only need to allow https traffic to the app load balancer and then you can accept http for the target group if you like from the load balancer.