Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this 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 '13 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 '13 at 13:42

1 Answer 1

up vote 6 down vote accepted

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.

share|improve this answer
1  
You are right. Here is the bug which was fixed 3 months ago. issues.apache.org/bugzilla/show_bug.cgi?id=54047 –  hayalci Mar 3 '13 at 14:26

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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