0

On Amazon Web Services, I have an EC2 instance running Apache and mod_remoteip. The instance is behind a Virtual Private Cloud (VPC) hosted Elastic Load Balancer (ELB).

In the mod_remoteip config file, I have:

RemoteIPTrustedProxy 172.22.64.0/20

RemoteIPTrustedProxy 172.22.80.0/20

which are the us-west-1a and us-west-1c subnets that the ELB can reside in.

In Amazon Route 53, for both MyDomain.com and www.MyDomain.com, I have A-IPv4 Alias records that point to the ELB (example: dualstack.my-load-balancer-1-251757805.us-west-1.elb.amazonaws.com.) There are no AAAA-IPv6 records for the Hosted Zone.

This setup works great, allowing my code easy access to the user's IP address.

However, very occasionally, mod_remoteip fills in an IPv6 address as the user's IP address. This IPv6 address causes issues in my setup, as some outside services I work with will not accept an IPv6 address. I must keep the IP address limited to IPv4.

I was under the impression that since I have no AAAA-IPv6 Alias records for my domain in the Hosted Zone, and that because ELBs in VPCs only use IPv4 addresses (http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/elb-internet-facing-load-balancers.html) that mod_remoteip should never be passing my code an IPv6 address. Clearly this is not always the case.

My question is: Using standard Amazon Web Services infrastructure, or Apache/mod_remoteip configuration, is there some way to only allow visitors to connect to the ELB using IPv4 only?

Emile Bourquin
  • 1
  • 1
  • What are some examples of these IPv6 addresses you are seeing? – Michael Hampton Dec 08 '15 at 01:52
  • Can you point to specifically what shows that only legacy internet connections are allowed from clients? The docs you link to say it will always use both. – Jim B Dec 08 '15 at 01:57
  • @Michael Hampton, Some examples of addresses I am seeing are: 2607:fb90:b29:621:0:5:bfa7:7d01, 2600:1000:b03e:324d:0:44:cf1b:9001, 2601:1c0:8301:171e:ac61:3441:7693:3320, 2607:fb90:209b:2267:b1e3:4db6:680c:79ba – Emile Bourquin Dec 08 '15 at 04:53
  • @Jim B, I guess I'm assuming the line "Load balancers in a VPC support IPv4 addresses only" leads me to believe it should be IPv4 only? Could an IPv4 addressed ELB be contacted via an IPv6 client address? When setting up the Route 53 Alias, it only allows me to use the dualstack. prefix. In Classic ELBs, this would allow both IPv4 and IPv6, but I'm thinking in a VPC it's IPv4 only? – Emile Bourquin Dec 08 '15 at 04:53
  • @EmileBourquin thanks I skipped right over that. I think it probably is using v4 but mod_remoteIP overrides the client IP of the connection with the advertised useragent IP (according to the doc I found), and if you are using the dualstack alias many browsers will try v6 first, then v4 on fail. – Jim B Dec 08 '15 at 05:12
  • @Jim B, sorry, I also forgot to mention that in the mod_remoteip config file, I have: "RemoteIPHeader X-Forwarded-For", X-Forwarded-For is originally where the client IP address is riding, so mod_remoteip puts it into $_SERVER['REMOTE_ADDR'] (in PHP land). Sometimes there is an array of addresses in $_SERVER['REMOTE_ADDR'] , I'm wondering if this is where the IPv6 comes in? Also, I guess my point about Route 53 is that if there is no AAAA-IPv6 record for the domain, IPv6 should not work ever? – Emile Bourquin Dec 08 '15 at 05:19
  • and what (hopefully someone else knows) is the expected result when the source IP is from a dual stack machine? – Jim B Dec 08 '15 at 05:26
  • Backing up a bit; since I know this is not mod_remoteip's fault, really the question is: How do I prevent IPv6 addresses from showing up in the X-Forwarded-For header that the VPC-hosted ELB sends to the EC2 instance? – Emile Bourquin Dec 08 '15 at 06:01
  • 2
    T-Mobile, Verizon Wireless, Comcast... the usual suspects. Are you quite sure you can't do something else about the outside services that can't handle IPv6 addresses? (Passing them 0.0.0.0 seems to be common.) Not using IPv6 _does_ degrade connectivity for mobile users. And this "problem" isn't going away; IPv4 is going away. – Michael Hampton Dec 08 '15 at 12:56

1 Answers1

2
dualstack.my-load-balancer-1-251757805.us-west-1.elb.amazonaws.com

That's a hybrid record, capable of returning both A and AAAA responses, regardless (afaik) of how you provision it in your hosted zone but testing indicates that it will only return records for the alias's matching RR type, if you use it as an alias target. As a CNAME, of course, it will result in either class of record being returned.

I previously suggested removing the dualstack. prefix, but as you noted, with Alias records, you can't remove it -- but, further testing shows it doesn't cause any harm.

With a CNAME, you have the option of omitting it, or if for some reason you wanted ipv6-only, you could add the ipv6. prefix instead of dualstack.. However, I'll stop short of suggesting that this makes any difference, since an A alias behaves correctly when pointed at the dualstack. entry, returning only A and not AAAA, even if you ask.

If, as you indicated, and your domain name that's pointed to this ELB does not have an AAAA alias configured, and Route 53 does not respond with any records for an AAAA request for your hostname, then it seems most likely that the requests coming in with IPv6 X-Forwarded-For: have to be coming in for no good reason -- they're spiders, bots, etc., and could be blocked on that basis.

I commonly see incoming requests with one of my ELB's IP address in the Host: header (rather than a proper hostname from one of my domains), or with the ELB hostname itself in the host header. Those are not legitimate requests, and I block them with 503 Service Unavailable (with rules in HAProxy, which I typically run behind ELB for more granular http routing control).

If you have legitimate site visitor who's hitting you on IPv6, this requires investigation and explanation, but my suspicion is that the traffic you see isn't "real" traffic.

I have not found a way to actually block it "within" ELB.

Michael - sqlbot
  • 22,658
  • 2
  • 63
  • 86
  • I have tried not adding the dualstack prefix, but their javascript running on the Route 53 record edit page puts it back in! Choosing the ELB from the choices in the dropdown also adds the dualstack prefix. I suppose I could try to trick the form into not adding the dualstack prefix, but that seems a bit dicey to me. Turning off javascript may allow me to enter what I want, but I'm guessing the whole Route 53 interface would stop working, since it's pretty javascript heavy. I just tried disabling javascript, and it still insists on the dualstack prefix. Not sure how that's even possible! – Emile Bourquin Dec 08 '15 at 16:21
  • Interestingly, "dig www.MyDomain.com AAAA" returns nothing in the Answer section, while "dig www.MyDomain.com A" returns two IPv4 addresses for the ELB in the Answer section. My machine and ISP are IPv6 capable. – Emile Bourquin Dec 08 '15 at 16:27
  • I'll also add that not having the dualstack. prefix was how I solved the problem before, when I was using EC2 Classic. I've migrated all my infrastructure to VPC, use mod_remoteip instead of my previously homegrown code to pull the user's address from the X-Forwarded-For header, and am now faced with this IPv6 issue. – Emile Bourquin Dec 08 '15 at 16:40
  • I suspect I have a non-production domain somewhere behind an ELB. I'll find one and do some testing on it, and update with what I find. – Michael - sqlbot Dec 08 '15 at 18:27