Home / server / Questions / 484239
Accepted
hayalci
Asked: 2013-03-04 05:05:43 +0800 CST

Apache IPv4 deny directive blocks IPv6 addresses

  • 772

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.

apache-2.2

1 Answers

  1. Best Answer

    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.

    • 8