Disabling IPv6 Compatibility: Does not work

Website, Application, Performance DNS & Network
1

Hello,
how can i force IPv4 for my users?
I have already tried various solutions:

  • Disable ipv6 compatibility through the API (which result currently disabled in the Cloudflare dashboard)
  • Disable Onion Routing on Cloudflare dashboard
  • Disable any compatibility on our server by editing the grub file and editing the /etc/sysctl.conf file
  • Configure nginx by setting:
    • listen 0.0.0.0:80
    • resolver 8.8.8.8 ipv6 = off in both the server and location blocks
    • fastcgi_pass 127.0.0.1:9000 in the PHP block
    • Disable any IPv6 addresses in the set_real_ip_from directives
  • Edit the /etc/hosts file by commenting out every line about localhost on IPv6.

None of this works, an IPv6 keeps coming to the server.

It seems that the only solution is to require the user to set up DNS (like 1.1.1.1 / 1.0.0.1) on their computer, but not all of our users have the skills to do so.

Unfortunately we are forced to use IPv6 due to the generation of a security tocken (based on the IP address of the user) to another server that does not support IPv6.

I hope someone can help me.
Thank you

2

It’s a really bad idea to attempt to disable IPv6 connectivity for your domain - you should focus on fixing your application so that it works with IPv6.

Does your origin accept IPv6 connections? If so and you have a CNAME or AAAA record that returns an IPv6 IP, then Cloudflare will use that to connect to your origin where IPv6 is available. That has nothing to do whether the visitor connected to us over IPv4 or IPv6. That part you can control by removing those AAAA records in your Cloudflare dash or disabling IPv6 at your provider (if using a CNAME) - that said, again - really bad idea.

If your origin is just using IPv4 and you have issues with parsing the visitor’s IPv6 address to generate a token, you could try the Pseudo-IPv4 option:

https://support.cloudflare.com/hc/en-us/articles/229666767-Understanding-and-configuring-Cloudflare-s-IPv6-support#h_877db671-916a-4085-9676-8eb27eaa2a91

This relies on you using the cf-connecting-ip or x-forwarded-for headers.

3

Hello Simon,
thank you so much for your answer.
On my Cloudflare dash, I don’t have any CNAME or AAAA records, they are all A records.
Do I need to check this thing out somewhere else outside of Cloudflare?

I use a free Cloudflare plan, can this affect this issue?

It would be fantastic to be able to use the Pseudo-IPV4, but the service that verifies the token I was talking about, unfortunately, does not use Cloudflare, so it will not be able to validate the token because it will not match the IPs.

Thanks again

4

If you only have A records Cloudflare will not be reaching your origin over IPv6, so that’s not a concern.

If you disabled IPv6 compatibility via the API and the API returns a value of “off” then it should be disabled. You can test for this by running a DNS query for the AAAA type for your domain. e.g. if you have dig dig AAAA example.com. If that returns nothing, then IPv6 is disabled at the DNS level on Cloudflare.

At this point, you’d need to investigate the application to understand what IPv6 traffic is still reaching the origin and why.

6

By doing a dig on the site, there appear to be no AAAA values. I compared the results with another site, present on the same server, always using Cloudflare, and there would seem to be no differences between the first site (not working) and the second, except for the destination IP address. I attach the outputs:

Working website X[dot]com (IPv4 is returned)

root@hetz1:~# dig X[dot]com

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> X[dot]com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5612
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;X[dot]com.			IN	A

;; ANSWER SECTION:
X[dot]com.		300	IN	A	104.21.14.144
X[dot]com.		300	IN	A	172.67.159.174

;; Query time: 19 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jun 21 10:10:43 CEST 2022
;; MSG SIZE  rcvd: 73

root@hetz1:~# dig AAAA X[dot]com

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> AAAA X[dot]com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6315
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;X[dot]com.			IN	AAAA

;; AUTHORITY SECTION:
X[dot]com.		3600	IN	SOA	igor.ns.cloudflare.com. dns.cloudflare.com. 2279305874 10000 2400 604800 3600

;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jun 21 10:34:49 CEST 2022
;; MSG SIZE  rcvd: 103

Not working website Y[dot]com (IPv6 is always returned)

root@hetz1:~# dig Y[dot]com

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> Y[dot]com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56568
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;Y[dot]com.	IN	A

;; ANSWER SECTION:
Y[dot]com. 300	IN	A	188.114.96.0
Y[dot]com. 300	IN	A	188.114.97.0

;; Query time: 9 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jun 21 10:10:58 CEST 2022
;; MSG SIZE  rcvd: 87

root@hetz1:~# dig AAAA Y[dot]com

; <<>> DiG 9.11.3-1ubuntu1.16-Ubuntu <<>> AAAA Y[dot]com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50217
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;Y[dot]com.	IN	AAAA

;; AUTHORITY SECTION:
Y[dot]com. 3600 IN	SOA	elsa.ns.cloudflare.com. dns.cloudflare.com. 2281230876 10000 2400 604800 3600

;; Query time: 5 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Tue Jun 21 10:34:58 CEST 2022
;; MSG SIZE  rcvd: 114

The two sites have the same nginx configuration and reside on the same server but on two different Cloudflare accounts (this is because X[dot]com belongs to my customer).
Here is the API response regarding IPv6 support for both sites:

X[dot]com:

root@hetz1:~# curl -X GET "https://api.cloudflare.com/client/v4/zones/MY_XCOM_ZONE_ID/settings/ipv6" \
>      -H "X-Auth-Email: MY_XCOM_EMAIL" \
>      -H "X-Auth-Key: MY_XCOM_KEY" \
>      -H "Content-Type: application/json"

{
   "result":{
      "id":"ipv6",
      "value":"off",
      "modified_on":"2022-05-29T10:29:32.540551Z",
      "editable":true
   },
   "success":true,
   "errors":[
      
   ],
   "messages":[
      
   ]
}

Y[dot]com:

root@hetz1:~# curl -X GET "https://api.cloudflare.com/client/v4/zones/MY_YCOM_ZONE_ID/settings/ipv6" \
>      -H "X-Auth-Email: MY_YCOM_EMAIL" \
>      -H "X-Auth-Key: MY_YCOM_KEY" \
>      -H "Content-Type: application/json"

{
   "result":{
      "id":"ipv6",
      "value":"off",
      "modified_on":"2022-05-29T10:31:45.860975Z",
      "editable":true
   },
   "success":true,
   "errors":[
      
   ],
   "messages":[
      
   ]
}

Do you have any advice on what to see? I honestly don’t know where to look anymore, I’ve tried them all

Thank you

8

So your dig commands there will only ever return A or CNAME. You need to dig explicitly for the AAAA (IPv6) records:

dig AAAA cloudflare.com

If that command returns no result, then IPv6 is definitely disabled, if you get IPv6 addresses back then that explains how IPv6 clients would be reaching you via Cloudflare.

You can also test via an online tool from multiple places, such as:

https://dig.ping.pe/cloudflare.com:AAAA:1.1.1.1

I can’t advise you because I don’t know your application - it’s best to speak to the developers and have them debug why IPv6 is a problem for them, assuming that is definitely the issue.

9

Sorry I entered the answer with the dig command AAAA late, no result anyway, even using the site you suggested.

It is a simple PHP application based on the Laravel framework. In any case, I did my tests by bypassing Laravel and creating a page that prints $ _SERVER and then analyzing all the headers that Cloudflare sends me.
The answers regarding IP addresses are completely different for two sites hosted on the same server, reached by the same client (same computer, same browser), but on two different Cloudflare accounts.

I am the developer of this project, unfortunately the need to avoid IPv6 is essential to ensure that the token system works and that our users can access all content. Unfortunately the service we use and which validates the token we send, only works with IPv4 addresses, we have already tried to contact them and their response was to ask us to disable IPv6 on our server.

It is really frustrating to know that there is no solution to this problem.

10

You’ll need to debug what is happening when you see the problem - given your dig AAAA results, IPv6 addresses are not returned on Cloudflare’s edge for your domain. So finding an impacted client and running those dig commands and a packet capture would be worth doing to understand what is happening between the client and the domain - e.g. what source & destination IPs are being used. From there you can attempt to unravel things further.

It sounds flippant but I don’t mean it this way - if you have a provider giving you software designed to run on the public internet that doesn’t support IPv6 - you might need to consider different software, honestly. That seems preferable to making your site inaccessible to large (and increasing) numbers of clients because they can’t handle an Internet Protocol that is decades(?) old at this point.

11

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