Edit I have thought that excessive number of "deny" lines are confusing apache into blocking unlisted IPv4 addresses. But comment of @Ladadadada made me pinpoint the exact issue. You can read my old question below. The problem is, the following line:

deny from

blocks the IPv6 addresses


How is this possible?

I have a really long list of blocked IP addresses, activated by an Include directive inside the Directory block.

This file only contains IPv4 addresses, but my server is also blocking a limited number of IPv6 addresses. It's not blocking all IPv6 traffic. If I remove the blocks, those IPv6 addresses can access the server just fine.

Originally the block file had each IP block on a separate "deny from" line. I tried combining every 40 of them to reduce the rule count and file size. It still did not help. But when I truncated the rules to 4-5 deny lines, it worked as expected and did not block the IPv6 addresses.

These are sample logs from access log.

2a01:4f8:120:8201::2 - - [03/Mar/2013:15:01:07 +0200] "GET /tdf/ HTTP/1.1" 403 387 "-" "MirrorBrain Probe (see http://mirrorbrain.org/probe_info)"

and from error log

[Sun Mar 03 15:01:07 2013] [error] [client 2a01:4f8:120:8201::2] client denied by server configuration: /mirror/pub/tdf/

How can I list a large number of "deny" directives ? I cannot control the firewall of the machine, so it's out of the question.

  • Can you narrow it down to the single line that's blocking the IPv6 address above and include that line in the question?
    – Ladadadada
    Mar 3, 2013 at 13:13
  • Thanks for the tip, I thought It was because of the number of blocked IP blocks. Now it seems that there is a single rule that's blocking the IPv6 IPs. I'm trying to pinpoint it.
    – hayalci
    Mar 3, 2013 at 13:42

1 Answer 1


Driving straight into the details, let's convert both and 2a01:1e8 into binary (you'll see why I only chose the initial portion in a moment.)

0010 1010 . 0000 0001 . 000 |
   42     .     1     . 0   |

0010 1010   0000 0001 : 000 | 0 0001 1110 1000
         2a01         :     |  1e8
                            ^ cut here

The way CIDR notiation works, is it'll match the first /X bits. In your case, it'll match the first 19, which 2a01:1e8:... also matches.

This leads me to believe it's a bug, since this is exactly the usage demonstrated in their documentation.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.