Bug #1889


Add support for IPv6 in mod_extforward

Added by mohanjith about 15 years ago. Updated almost 12 years ago.

Target version:


I have a proxy (varnish) which listens on a IPv6 address and forwards requests to Lighty on IPv4 address. Requests seems to be coming Lighty's way they seem to be originating from However mod_extforward cannot be made to trust this IP. mod_extforward works perfectly when the clients are connecting to the proxies IPv4 interface.


patch-src_mod_extforward.c (981 Bytes) patch-src_mod_extforward.c IPv6 support for addresses lapo, 2010-02-19 13:14
extforward.patch (1001 Bytes) extforward.patch TitPetric, 2012-03-13 11:16
Actions #1

Updated by lapo almost 15 years ago

I've got an IPv4 & IPv6 varnishd with a lighttpd backend, I can succesfully trust, but when connecting from an IPv6 address such as ....:CB76 inside the logs and PHP I see it as

Actions #2

Updated by nitrox almost 15 years ago

try "cat /proc/sys/net/ipv6/bindv6only", which should be set to 1, if set to 0 its using kind of ipv4-over-ipv6 (dunno the correct wording atm.) and use $HTTP["socket"] "[::]:80" and $HTTP["socket"] ":80" to bind on v6 and v4 seperately (might interfere with server.use-ipv6 = "enable", so comment this out first).

Dunno if this really solves your problem, but atleast v4 and v6 work independent from each other. Look at the logs, it should have "real" v4/v6 ip-adresse logged.

Actions #3

Updated by lapo almost 15 years ago

@nitrox: this bug isn't about IPv6 support in lighttpd (that works great for me), this is about supporting (even in a purely-IPv4 lighttpd) IPv6 addresses in X-Forwarded-For field in mod_extforward: right now it parses them (incorrectly) just like IPv4, giving weird 0.0.0.x addresses as opposed as the correct address.
PS: I'm using FreeBSD so what you suggest would be translated as "sysctl net.inet6.ip6.v6only=1", but that've been the default value on FreeBSD for a while already...

Actions #4

Updated by lapo about 14 years ago

I think the attached simple patch can solve the problem and allow to parse IPv6 addresses.
Question: why did it accept ':' already, if IPv6 addresses were not supported?

Actions #5

Updated by omero about 14 years ago

I can confirm the patch is perfectly working.

I've download and patched my lighttpd and is correctly showing IPV6 now.

You can check this by connecting from a ipv6 address to: [[]]

You will see your correct IPV6 address.

THank you lapo for the very easy, but VERY MUCH NEEDED patch!

Actions #6

Updated by TitPetric almost 12 years ago

  • Target version set to 1.4.31
  • % Done changed from 0 to 100

In lighttpd 1.4.30 the same error is still existing, patch has not been included. My setup is:

Front end nginx load balancer, several back end lighttpd web servers.

1. load balancer receives ipv6 request
2. extforward has ip listed under extforward.forwarders
3. IPV6 IP 2002:598f:9b0c:0:21b:63ff:fec9:849a -> (mod_extforward.c.327) could not resolve hostname 9:849 because Name or service not known (Success)
4. IP logged in access.log is the load balancer IP, instead of the IPV6 above.

Please include this patch in production lighttpd, it is available for 2 years here, and should be included in next release if possible.

Actions #7

Updated by TitPetric almost 12 years ago

Fixed patch to include ':' as a valid ip notation because loadbalancer for me was forwarding ipv6 mapped ipv4:

::ffff:XX.XX.XX.XX = valid ipv4 to ipv6 mapping.

Hence: (mod_extforward.c.327) could not resolve hostname ffff:XX.XX.XX.XX because Name or service not known (Success)

Patch attached and tested.

Additional effects: Access log includes ipv6 mapped ipv4 addresses now:

::ffff: hostname - [date] ...

(::ffff: is not trimmed from beginning - not really an issue for us, PHP backend aparently trims it automatically).

Best regards

Actions #8

Updated by stbuehler almost 12 years ago

  • Subject changed from Add support for IPv6 to Add support for IPv6 in mod_extforward
  • Missing in 1.5.x set to No
Actions #9

Updated by stbuehler almost 12 years ago

  • Status changed from Patch Pending to Fixed

Applied in changeset r2837.


Also available in: Atom