Hi Guillaume!
It looks like you and Carlos are both correct. For some reason, before I was
not seeing the Varnish XFF values from faked XFFs, not sure why, but now I’m
seeing the fakes I’m using against one of my dev sites and I’m seeing the three
values where it’s FAKED_IP, REAL_IP, ALB_IP.
Hi,
If I read this correctly:
https://docs.aws.amazon.com/elasticloadbalancing/latest/application/x-forwarded-headers.html
, you can trust the before-last IP, because it was added by the ALB,
always. (and using vmod_str makes it easy to retrieve
Hi,
No so sure about that. Let's assume the client address is 1.1.1.1. Two possible
scenarios:
- The client request reaches the ALB without XFF. The ALB will inject XFF with
value 1.1.1.1. Then Varnish will modify XFF adding the ALB's address (i.e.,
1.1.1.1,). Using the next-to-last IP you're
Hi Carlos,
Correct, but that’s my problem. There are only two IPs in XFF: the original
sender (and thus the one that can be spoofed) and the ALB’s IP, which is
basically useless. I realize I can’t trust the first IP, but the client IP
being the ALB doesn’t help because I need to restrict by
Hi Justin,
You cannot rely on the first IP in XFF (I guess you're doing that at the
moment), but you can rely on the next-to-last. The last one is added to XFF by
Varnish before entering 'vcl_recv', and the next-to-last is added by the ALB.
That's the client IP as seen by the ALB and cannot be
Hi all,
Is anyone else running Varnish behind AWS ALBs? I just encountered an issue
today with how I have been using X-Forwarded-For to check against a Varnish ACL
in that is more restrictive than the ALB's security group, but I realized the
hard way that since X-Forwarded-For can be
