Make HAProxy stop prepending ::ffff: to IPv4 addresses in X-Forwarded-For

Help!
1

This is a minor issue, but it’s driving me crazy. I don’t know why and I apologize in advance for being dumb, but I cannot get HAProxy to use plane-jane IPv4 addresses when adding an X-Forwarded-For header. Regardless of whether I’m using option forwardfor or doing add-header X-Forwarded-For %[src], HAProxy only renders IPv4 addresses as IPv6-mapped IPv4s (so traffic from 123.456.789.123 gets an X-Forwarded-For header that reads ::ffff:123.456.789.123).

This is obviously not a huge problem, but it’s causing annoying issues with downstream applications that aren’t expecting IPv6-mapped IPv4 addresses.

My current workaround is to use a downstream proxy (Varnish, in this case) to edit the headers in flight and remove the ::ffff: if present. This is obviously non-optimal because it adds complexity and overhead, however small.

IPv6 addresses are obviously rendered correctly in the header. HAProxy is bound and listening to ports 80 and 443 for both ipv4 and ipv6 traffic (with bind :::80 v4v6 and bind :::443 v4v6. There is only one backend and traffic is passed to it via UDS.

Any suggestions would be appreciated. I feel like this is a stupid question and there’s probably something really obvious I’m overlooking, but I’ve been screwing with this all day and I’m not sure what it could be. Happy to post configs if necessary.

Happy New Year to everyone :slight_smile:

2

Don’t configure the listening socket for both families, instead, create a IPv4 socket and an IPv6 socket:

bind *:80,:::80 v6only
bind *:443,:::443 v6only ssl crt ...
1 Like
3

Hi @lukastribus - thank you, that seems to have done the trick. (though there’s an extra space between the two port ranges, for anyone who is going to cut-n-paste that solution). I appreciate the help!

4

Thanks, fixed.