QS_ClientGeoCountryDB IPv6

[Simon Studer]

Is there a way to define IP ranges for IPv6 just like for IPv4 using QS_ClientGeoCountryDB ?
The documentation only talks of IPv4: http://mod-qos.sourceforge.net/index.html#QS_ClientGeoCountryDB.

The reason I am asking is because we are seeing IPv6 addresses being blocked by QS_ClientGeoCountryPriv because they are not associated with one of the whitelisted countries correctly.

[Pascal Buchbinder]

QS_ClientGeoCountryDB supports IPv4 only (can't be used for servers supporting IPv6).

[Pascal Buchbinder]

Alternatively (although not no connection level) you could use QS_EventRequestLimit together with a module like https://github.com/ip2location/ip2location-apache or https://github.com/maxmind/mod_maxminddb

[Simon Studer]

Are there any plans to implement support for IPv6?

[Pascal Buchbinder]

IPv6 csv files are huge and it's better to use binary db files which I don't want to support. Better to use a solution / module offered by the provider of these db files.

[Simon Studer]

Thank you, we will see how we proceed.

[Simon Studer]

I was wondering would it be possible to add the following features to mod_qos?
Assign a non-existent country code to IP addresses that cannot be assigned a country code according to the mod_qos GeoIP DB (for example XX)? This would allow these IP addresses to be whitelisted if there are issues.
Allow using an environment variable to be used to get the country code (like from mod_maxminddb) instead of looking it up from the mod_qos GeoIP DB.

[Pascal Buchbinder]

We could enhance QS_ClientGeoCountryPriv by a third argument telling mod_qos to ignore clients whose address can't be mapped to a country code.
And as mentioned above: you can use modules such as mod_maxminddb or mod_ip2location together with any environment variable based rule, such as QS_EventRequestLimit.

[Simon Studer]

The reason I would be hesitant to use QS_EventRequestLimit to replace QS_ClientGeoCountryPriv is that, looking at the documentation, there does not appear to be an easy way to negate the match, as there is with QS_EventPerSecLimit, for example.
Further, regexes with negative lookarounds are comparitively complicated to formulate and error prone and there are a number of subtle tweaks required to make them run efficiently, as far as I know.
Finally, these Limits do not run at connection level as you already mentioned above.

For these reasons I would argue that an additional flag for the QS_ClientGeoCountryPriv would be a much better solution. Even better would be if, additionally, the country code used for the QS_ClientGeoCountryPriv evaluation could be configured to come from an environment variable provided by another module.

Do you know whether the other modules you named run early enough to set the environment variable in time for it to be used by QS_ClientGeoCountryPriv?

[Pascal Buchbinder]

You can simply suppress a limit for known countries by clearing the variable for known country codes.
Configuration might look like this:

MaxMindDBEnv COUNTRY_CODE COUNTRY_DB/country/iso_code
SetEnv LimitCountry
QS_SetEnvIf COUNTRY_CODE=CH|DE|AT !LimitCountry
QS_EventRequestLimit LimitCountry 100

Sure QS_ClientGeoCountryPriv is much more efficient because clients are already blocked at the connection level. But you could still combine the two options I suggested last Wednesday.

[Simon Studer]

I see. This should make for an acceptable workaround to limit IPv6 as well. However, I am not sure how this could be combined with QS_ClientGeoCountryPriv without locking out all IPv6 Addresses once QS_ClientGeoCountryPriv becomes active.

If I am not mistaken, this would still require that additional parameter for QS_ClientGeoCountryPriv you mentioned above:

Pascal Buchbinder - 6 days ago
We could enhance QS_ClientGeoCountryPriv by a third argument telling mod_qos to ignore clients whose address can't be mapped to a country code.

[Pascal Buchbinder]

Yes, IPv4 clients are handled by QS_ClientGeoCountryPriv. Addresses which can't be resolved by mod_qos (e.g. all the IPv6 clients) shall be ignored by QS_ClientGeoCountryPriv (new mode excluding those clients which can't be mapped to a country code).

Those unresolved clients are then mapped to a country code by a third party module (later in the request processing) and access can be restricted by another mod_qos rule, e.g. QS_EventRequestLimit.

[Simon Studer]

Ok, thank you. Then we will wait for the new release and implement the suggestion above as soon as it is available.

[Pascal Buchbinder]

mod_qos 11.70

 QS_ClientGeoCountryPriv <list> <connections> ['excludeUnknown']

[Simon Studer]

Thanks. Will upgrade and report back.

[Simon Studer]

Appears to work as expected, thank you.