IP Firewall Restriction - Block / Allow IP4 IP6

My IP6 changes, my IP4 stays the same. Cloudflare IP restriction ignores the IP4 and blocks based on the IP6. The IP4 restriction works normally via Apache but Cloudflare seems to be backwards.

How are you setting your blocks and allows?

Cloudflare only checks the IP address that’s making the request. Right now, I’m probably connecting to this Community with my IPv6 address. Whatever Cloudflare would do with IPv4 addresses won’t apply to me. Any IPv6 restrictions would.

Thank You.

Firewall / Firewall Rules - URI Path Action BLOCK
Firewall / Tools - IP Access Rules ALLOW

It appears that Cloudflare only identifies the IP6 and ignores the IP4 when both IP4 and IP6 are present.

Allowing IP6 - server logs show the requesting IP6 and Cloudflare IP4s (replacing the request IP4).

Allowing the requesting IP4 (opposed to the IP6) has no effect, results in block.

Works fine with Apache, does not work with CF. Seems to be CF limitation or bug.

I’m still not clear on this. How are both IPv4 and IPv6 present at the same time?

Let’s focus on one first. IPv6 seems to be the issue. In my Allow list, I have a /64 range set to Allow:
1234:1234:1234:abce:0000:0000:0000:0000/64

At some point, my IPv6 changed slightly, while my IPv4 did not. Old value was something like:
1234:1234:1234:adde:0000:0000:0000:0000/64

Beyond that, I don’t check my IPv6 address to see if it changes within the /64 range. Had I opted for a /48 range earlier, I wouldn’t have been blocked, but it is a wider range that’s most likely still pretty safe for my threat model.

Have you tried a /48 to allow your IPv6 requests?

1 Like

Thank You

“I’m still not clear on this. How are both IPv4 and IPv6 present at the same time?”
ISP supports both and it’s fairly common nowadays, it will show space separated in server logs like-
123.123.123.123 1234:1234:123:123d:: [time] etc.

Displays both IPv4 and IPv6, if both are present What Is My IP | Check Your Public IPv4/IPv6 Address Location

As for Cloudflare firewall logs, they only display the IPv6, if both IPv6 and IPv4 are present.

The IPv6 range would work fine as you mentioned.

Why Cloudflare is not able to identify the IPv4 when both IPv4 and IPv6 are present remains a mystery, seems to be a bug or limitation of Cloudflare.

Browsers can’t use IPv6 and IPv4 at the same time for the same connection. It’s like having a two-line telephone to call someone. You dial out on one or the other, and their Caller ID isn’t going to show both phone numbers you have on your phone. They may block all callers, but Allow your Line 2. So if you call from Line 1, you’re still going to get blocked.

Thank You

The phone scenario is off track. When an IPv4 and IPV6 are both present, a typical server or firewall can identify and act on each. Cloudflare cannot act on IPv4 when both IPv4 and IPv6 are present. It’s either a bug or just a limitation with Cloudflare.

The problem is not limited to IPv4 allow. If an IPv4 is blocked when both IPv4 and IPv6 are present, the block action has no effect. This firewall behavior is not typical or expected, it’s a security issue that appears unique to Cloudflare.

I think you are misunderstanding how a dual stack client actually works.

If I have both IPv6 and IPv4 addresses on my device/client, only one of those will be used to make a particular connection to Cloudflare. In general, clients will attempt to connect using both versions, and use the one that succeeds, or is faster (normally with a weighted preference for IPv6), is the only one that is used to make HTTP requests.

The connection seen by the Cloudflare Firewall with be either IPv4 or IPv6. It will not be both at the same time. So firewall rules that block IPv6 will never block an IPv4 address and vice-versa.

It is a limitation of the nature of networks. If you have a lock on the front door of your house it does not magically lock the back door also.

5 Likes

The door scenario is not applicable. You understand both the IPv4 and IPv6 are present. Apache can identify and act on each, either and both with no problem what so ever. When an IPv4 is disallowed, Apache will not allow it, even when a coexisting IPv6 is present. Same is true no matter which way you flip it around., basic firewall stuff and expected behavior. Cloudflare is not able to identify or act on an IPv4 if an IPv6 is also present. It’s not a network limitation, it’s a Cloudflare limitation or bug.

It is not anything specific to Cloudflare.

A particular single connection / request uses IPv4 or IPv6, no information about the other address scheme is provided. Test this using curl or something other than a full browser for more visibility about what is happening.

Test sites can retrieve both by performing additional requests to servers that accept only IPv4, and another that accepts only IPv6, but this is because they intentionally force your browser to make multiple connections to different server addresses just to fulfill this need. Cloudflare doesn’t.

Testing this from a bowser is a little complicated because modern browsers will initially make an IPv4 connection and an IPv6 connection when they see A and AAAA records. These connections are totally separate and not connected to each other from the perspective of the server. Browsers do this because the network conditions can be very different, so your browser will then pick the faster one and stick with it until there is reason to change.

Apache is a great way to see how this works if you run your own server and have log access. Check your logs for a given single request, do you see the IPv4 or IPv6 address in the log? Now where in that same log entry is the other address?

Now, you will find that blocking either IPv4 or IPv6 often blocks both, and here is why: The browser users whatever responds first, so consider what is faster, a .htaccess deny directive or generating and delivering the real page? The error will often be faster to generate and smaller to deliver, so all other things being equal, the blocked IP gets priority.

In the real world, all other things are not equal and you cannot rely on this. For example, if you are delivering a cached “hello” page, that might be smaller than Cloudflare’s “you’re blocked” page, so the browser may get the real content before the error. This is guesswork and it doesn’t matter because it will not be consistent or reliable.

I hope this helps!

4 Likes

You got it. The part throwing me the curve was the logs.Normally there is one IP; far left and it’s the origin. The line starts with the intermediate IPv4 immediately followed by the IPv6 or IPv4 origin. So 2 IPs where one should be, one proxy the other real and actual origin moved over the right. The server seems to see both the IPs as origin and so did I initially, but one is the intermediate.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.