We can’t accept IPv6 requests and require only IPv4 in the CF-Connecting-IP.
Our clients require us to match our users against a dynamic list of IPv4 addresses. Therefore, we have no choice to support IPv6 at this point.
To disable IPv6, we turned off “IPv6 Compatibility” via API. But we still receive IPv6 requests in the CF-Connecting-IP header. How can we fix that so that we are only available via IPv4 and only receive IPv4 as CF-Connecting-IP? Pseudo IPv4 won’t help us as we need the real IPv4 to fulfil our obligations with our clients.
We tried to fix it by creating a custom rule via Security/WAF to block ip.src in {::/0}
Unfortunately this does not properly enforce IPv4 but completely blocks users that have previously been able to access our application via IPv4 before we moved to Cloudflare.
I’m gonna start with the usual caveat, it’s pretty much impossible nowadays to ignore IPv6-only clients. They exist and will exist more and more. Especially as IPv4 addresses are more and more shared between multiple clients/users.
Now, need to disable IPv6 support altogether via the API, which is for now, supported. I’m not sure how long that will last, but it’s just disabled in the UI at the moment.
Cloudflare by default adds IPv6 (or IPv4) to any proxied domain, even if just one of A/AAAA records exist.
Before we migrated to Cloudflare, our applications were only available via IPv4 and we never received a single complaint about being unavailable. I believe IPv4 availability is still good enough. We’d love to support IPv6, but our clients require us to match our users against their lists of IPv4 addresses. If we send in a user that’s on their IPv4 blocklist, we are violating our contracts.
Your clients are going to need to abandon their inefficient and obsolete methods or get left behind. Clearly their customers are already on IPv6 even if they themselves are not.
While I agree with you, I’m afraid this won’t help to find a solution to the problem.
Our clients are multi-billion $ corporations that move slowly. We can either give up our business with them or make it work with IPv4 for the time being.
That being said, before migrating to Cloudflare today, we were available only under IPv4 and never had availability issues with serving millions of users every month. IPv4 availability clearly is still good enough.
For now we had to disable the Cloudflare Proxy. Is it possible to fully disable IPv6 with Cloudflare? As mentioned, turning it off via API did not help. The same users that requested our application via their IPv4 for the last few months started to request via IPv6 immediatley after migrating to Cloudflare despite IPv6 Compatibility turned off.
We would also consider a Cloudflare Enterprise plan if this is required to fix the issue. Is anyone from the Enterprise support team here?
It’s kind of ironic to think of lumbering old corporations as internet dinosaurs, considering what happened to the dinosaurs.
I’m not unsympathetic to your plight, even if I find the willful ignorance of organizations such as your clients to be excruciating.
You would need an Enterprise agreement to engage with Enterprise support staff, and that would not be likely to occur here in the Community. Your best bet will be to book a sales call if Cloudflare Enterprise is something that important to your customers. I don’t know if Cloudflare is on a holiday schedule. If they are you might not see movement until Wednesday, but it would not hurt to put in your request now.
Earlier today I wasn’t able to reach the Enterprise team via phone. A few hours ago I submitted the contact form you sent. I still hoped there was an “easy solution” for this but it seems unlikely.
If you are still receiving IPv6 addresses it is likely because you are using pages, workers or another Cloudflare function which processes requests internally on Cloudflare. It may be the visitor’s IPv4 is in the x-forwarded-for header in which case you can parse and send it from there.
Also you’ll want to make sure your origin only has an IPv4 address.
We do use Cloudflare Pages, but only for frontend. In our case, frontend and backend are separate applications.
app.domain.com is the frontend on Cloudflare Pages api.domain.com is the backend which is using Cloudflare’s proxied DNS. It receives IPv6 IPs in CF-Connecting-IP despite IPv6 Compatibility turned off
As not the frontend itself but the browser requests the API, this should not have any impact on the IPs or does it?
Our servers only have an IPv6 address and are not reachable via IPv6. From what I understand, Cloudflare requests our servers only via IPv4. The issue is that they let users access their end with an IPv6, which results in IPv6 addresses in CF-Connecting-IP.
domain.com has no AAAA records. But as you said, Cloudflare probably adds AAAA records on their end that we can not see for proxied domains.
You can see the AAAA records in the results of a DNS query. Any records that are proxied will have AAAA records published that point to the Cloudflare proxy. I have never used the API to disable IPv6, but I would expect that you should not have any AAAA records returned if it worked.
In the Network dashboard you have the option to activate Pseudo IPv4.
Cloudflare offers Pseudo IPv4 which supports IPv6 addresses in legacy applications expecting IPv4 addresses. The goal is to provide a nearly unique IPv4 address for each IPv6 address, using Class E IPv4 address space, which is designated as experimental and would not normally see traffic.
Unfortunately, the Pseudo IPv4 feature won’t help us as we need the real IPv4 of our users. The reason is that our clients provide us lists of IPv4 addresses that we must validate against our users. We violate our contracts with our clients if we send in users that were not validated against their IPv4 lists. Our clients are large organizations that don’t support IPv6 yet and probably won’t support it soon.
The problem is that we turned off IPv6 Compatibility but users are still accessing our website via IPv6 it seems, which results in IPv6 IPs in CF-Connecting-IP. That’s problematic as we can’t validate these against the lists of IPv4 addresses from our clients.
To be clear, the IPv6 IPs do not come from IPv6-only users. They come from the same users that accessed our website via IPv4 for weeks/months and suddenly have an IPv6 since we started using Cloudflare’s proxified DNS.
@louise2 Is there a way to completely disable IPv6? Is there any other setting that might conflict with the IPv6 Compatability setting which we successfully turned off via the API?
We would definitely get a paid Pro plan at least. We’re just not sure right now if Cloudflare can offer what we need.
As mentioned in the initial post, creating the Firewall rule made our website unavailable for some users. These users had previously accessed our application via their IPv4 addresses and were then blocked for using an IPv6 after we migrated to Cloudflare and added the Firewall rule.
The Firewall rule blocks IPv6 instead of enforcing IPv4.
Note that we’re not talking about IPv6-only users (which barely exist), but about users that have an IPv4, but Cloudflare let’s them connect with their IPv6, just to then block them based on the Firewall rule.
proxied will have AAAA records published that point to the Cloudflare proxy. I have never used the API to disable IPv6, but I would expect that you should not have any AAAA records returned if it worked.