4

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 42.1.0.0/19

blocks the IPv6 addresses

2a01:4f8:120:8201::2
2a01:1e8:e100:ce::2

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.

2
  • 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

8

Driving straight into the details, let's convert both 42.1.0.0 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.

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .