Enabling ipv6 makes matching subnets with $HTTP["remoteip"] inoperable.
When ipv6 is enabled, clients connecting via an ipv4 address are recorded in the accesslog with a ::ffff: in front of the ipv4 address. Here is an example line from my accesslog:
::ffff:18.104.22.168 - - -0800 "GET /linux/core/4/i386/os/repodata/repomd.xml HTTP/1.1" 200 1140 "-" "urlgrabber/2.9.6"
This seems to prevent matching of remote ip's via subnet. If I do:
I never get a match, even from addresses from within that range.
Similarly, $HTTPremoteip "::ffff:127.0.0.1/8" also doesnt work.
The exact match: $HTTPremoteip == "::ffff:127.0.0.1" does work indicating that the ipv6 mess at the front is causing the problem.
This problem seems to go away when lighttpd is bound to an interface with no ipv6 address associated with it.
Updated by stbuehler about 4 years ago
- Description updated (diff)
I wrote a patch that enables
$HTTP[remoteip]comparisons for IPv6 addresses.
It will also compare a remote v6-mapped v4 address to a v4 address in dotted-quad notation.
Hi, sorry it took me so long to respond. Please open a new issue for this, and I'd like to get rid of the v6-mapped v4 address matching part. Our preferred configuration is to use bindv6only, and not doing any magic (see IPv6-Config).
Also available in: Atom