- Newest
- Most votes
- Most comments
Hello, from what you write, I understand that:
- With the
AllowOnlyFromLoadBalancer
security group applied to your EC2, it becomes unreachable from CloudFlare IPs. - With the
AllowOnlyFromCloudFlareIPs
security group applied to your EC2, it becomes reachable from CloudFlare IPs.
Are you sure that, from CloudFlare, you are pointing to the ALB and not directly to the public IP address of your EC2 instance?
Hello @Vincent, thank you.
Are you sure that, from CloudFlare, you are pointing to the ALB and not directly to the public IP address of your EC2 instance?
Yes, I'm sure that CloudFlare is pointing to the ALB and not directly to the public IP.
One thing I did not mention in my question is that the EC2 instance requires both security groups to work as I want. If either of them is missing, the instance becomes entirely unreachable.
I will edit my original question to add this information too.
Is it an application load balancer or a network load balancer? If it's an NLB then these preserve the source IPs, so from the EC2's perspective the traffic will look like it's all coming from CloudFlare IPs.
This would be consistent with the behaviour you describe.
https://aws.amazon.com/elasticloadbalancing/network-load-balancer/
Preserve source IP address
Network Load Balancer preserves the client side source IP allowing the back-end to see the IP address of the client. This can then be used by applications for further processing.
Thank you @Steve, it's an application load balancer as far as I can tell from the console.
As its an ALB that means it has to be web traffic, so there will be a webserver listening on the EC2. Do the webserver logs offer any clue as to the source of the incoming traffic, I mean are they seen as coming from the ALB's private IP or the CloudFlare IPs?
Also, what rules are in the security group that's associated with the ALB? I'm guessing it will be something like inbound 80 & 443 from CloudFlare IPs, and then outbound 80 to the EC2's private IP? Or does the outbound rule reference one or other of the SGs AllowOnlyFromCloudFlareIPs or AllowOnlyFromLoadBalancer? Whichever of these SGs is in the ALB's rule is going to have to be associated with the EC2 in order for traffic to be allowed (and I think it should be AllowOnlyFromLoadBalancer).
If the ALB outbound rule references one of those SGs, how about replacing that rule (just for troubleshooting purposes) with the private IP of the EC2 and see if it improves things?
As its an ALB that means it has to be web traffic, so there will be a webserver listening on the EC2.
Exactly, there is an apache web server.
Do the webserver logs offer any clue as to the source of the incoming traffic
That's a good idea. I edited httpd config to have the following log format:
LogFormat "'Forwarded for - %{X-Forwarded-For}i' %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
And I got the following log:
'Forwarded for - my.ip.address, cf.ip.address' alb.private.ip.address - - [21/Sep/2023:12:25:51 +0000] ...
So it seems that incoming traffic is coming from ALB's private IP while, in order, my laptop IP address and a CF ip address are listed in the forwarded for section.
Also, what rules are in the security group that's associated with the ALB?
There are 2 inbound rules:
- type:
HTTP
source:0.0.0.0/0
(any ip) - type:
All Traffic
source: the alb security group itself
Ant there is 1 outbound rule:
- type:
All Traffic
destination:0.0.0.0/0
There is no cloud flare rule associated to the ALB.
If the ALB outbound rule references one of those SGs, how about replacing that rule (just for troubleshooting purposes) with the private IP of the EC2 and see if it improves things?
I can try to add an outbound rule with the privete IP of the EC2 and associate it with the ALB. But this is risky because we have a bunch of services behind this ALB and for some of them I cannot have downtime.
Relevant content
- AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 months ago
- AWS OFFICIALUpdated a year ago
- AWS OFFICIALUpdated 2 months ago
I was just about to write a much longer response - but this is what I think as well.