1.1.1.1 appears to be blocked or hijacked by your ISP or your router

[Aiakio]

Hello there

I need help troubleshooting, please. Since for a lot of other people this is working, I fully expect, that the issue is somewhere in my network, i just don't know where or how to look / find it and need help with diagnosing. Just in case this is relevant information: Im running this on a Synology DS1520+ NAS behind a Synology RT6600ax Router.

I get

📖 Checking settings . . .
📖 Checking 1.1.1.1 . . .
   😞 1.1.1.1 appears to be blocked or hijacked by your ISP or your router
   😊 1.0.0.1 appears to be blocked or hijacked as well; sticking to 1.1.1.1

but i am not sure what that means. I do not (knowingly) block 1.1.1.1 or 1.0.0.1 on my network. And i am not sure if my router hijacked this (not sure what that means in the first place.). If i surf to 1.1.1.1 or 1.0.0.1 on a web browser, the page loads normally.

Sorry for this. Basically, I'm in the middle of learning this kind of stuff. But i couldn't figure that one out so far and need some help.

This is the entire log:

🌟 Cloudflare DDNS (v1.9.4-0-g68dc1f3)
🥷 Dropping privileges . . .
📖 Reading settings . . .
   🔸 Use default IP4_PROVIDER=cloudflare.trace
   🔸 Use default IP6_PROVIDER=cloudflare.trace
   🔸 Use default UPDATE_CRON=@every 5m
   🔸 Use default UPDATE_ON_START=true
   🔸 Use default DELETE_ON_STOP=false
   🔸 Use default CACHE_EXPIRATION=6h0m0s
   🔸 Use default TTL=1
   🔸 Use default DETECTION_TIMEOUT=5s
   🔸 Use default UPDATE_TIMEOUT=30s
📖 Checking settings . . .
📖 Checking 1.1.1.1 . . .
   😞 1.1.1.1 appears to be blocked or hijacked by your ISP or your router
   😊 1.0.0.1 appears to be blocked or hijacked as well; sticking to 1.1.1.1
📖 Current settings:
   🔧 Domains and IP providers:
      🔸 IPv4 domains:            [REDACTED]
      🔸 IPv4 provider:           cloudflare.trace
      🔸 IPv6 domains:            [REDACTED]
      🔸 IPv6 provider:           cloudflare.trace
   🔧 Scheduling:
      🔸 Timezone:                UTC (UTC+00 now)
      🔸 Update frequency:        @every 5m
      🔸 Update on start?         true
      🔸 Delete on stop?          false
      🔸 Cache expiration:        6h0m0s
   🔧 New DNS records:
      🔸 TTL:                     1 (auto)
      🔸 Proxied domains:         (none)
      🔸 Unproxied domains:       [REDACTED]
   🔧 Timeouts:
      🔸 IP detection:            5s
      🔸 Record updating:         30s
😞 Failed to send HTTP(S) request to "https://1.1.1.1/cdn-cgi/trace": GET https://1.1.1.1/cdn-cgi/trace giving up after 1 attempt(s): context deadline exceeded
😞 Failed to detect the IPv4 address
🔧 If your network does not support IPv4, you can disable it with IP4_PROVIDER=none
😞 Failed to send HTTP(S) request to "https://[2606:4700:4700::1111]/cdn-cgi/trace": GET https://[2606:4700:4700::1111]/cdn-cgi/trace giving up after 1 attempt(s): context deadline exceeded
😞 Failed to detect the IPv6 address
🔧 If you are using Docker or Kubernetes, IPv6 often requires additional setups
🔧 Read more about IPv6 networks at https://github.com/favonia/cloudflare-ddns
🔧 If your network does not support IPv6, you can disable it with IP6_PROVIDER=none
⏰ Checking the IP addresses in about 4m49s . . .

And this is my docker compose yaml deployed via Portainer:

    cloudflare-ddns:
        container_name: cloudflare-ddns
        image: favonia/cloudflare-ddns:latest
        network_mode: host
        restart: unless-stopped
        cap_add:
            - SETUID
            - SETGID
        cap_drop:
            - all
        read_only: true
        security_opt:
            - no-new-privileges:true
        environment:
            - PUID=1026
            - PGID=100
            - CF_API_TOKEN=[REDACTED]
            - DOMAINS=[REDACTED]
            - PROXIED=false

[favonia]

@Aiakio Thanks for the reporting. This seems to be a network configuration issue---that is, something in your network setup, probably Synology DS1520+ NAS or the Docker daemon on it, blocks the network access of the container. Are you able to run, say, the alpine image (or any general Linux distro image) and execute wget https//1.1.1.1 within the container? That would be a useful first step. That is, fire up a shell within a Docker container:

docker run -it alpine

and then within the container try these out:

wget -O - https://1.1.1.1/cdn-cgi/trace
wget -O - https://1.0.0.1/cdn-cgi/trace

If wget cannot download the pages, it means something is wrong with your Docker settings or Synology (or your router, though unlikely). You might have to check how to enable network access for your Docker containers.

PS: I noticed that the second error message comes with a smiling face... that is definitely a UI bug! :face_with_spiral_eyes: I will fix that later.

[Aiakio]

Thank you for taking the time to try to help me, @favonia.

I installed alpine and ssh'd into the nas -> container and ran the wget lines:

# docker run -it alpine
/ # wget -O - https://1.0.0.1/cdn-cgi/trace
Connecting to 1.0.0.1 (1.0.0.1:443)
wget: can't connect to remote host (1.0.0.1): Operation timed out
/ # wget -O - https://1.1.1.1/cdn-cgi/trace
Connecting to 1.1.1.1 (1.1.1.1:443)
wget: can't connect to remote host (1.1.1.1): Operation timed out
/ #

Each time, it took roughly 2 minutes for the 'operation' to time out.

What i noticed: if i replace the 1.1.1.1 / 1.0.0.1 with, for example, https://www.google.com i get no timeout and proper output. So, i guess, there seems to be really a problem specifically with 1.1.1.1 and 1.0.0.1. I wonder where this is coming from.

[Aiakio]

A little update: I tried to wget -O - https://1.1.1.1/cdn-cgi/trace while not in a container and just logged in via ssh to the nas i also get a timeout. If i ssh into the router (or use the built in ping function on the router itself) i do get output and it works on there.

So the problem is on the NAS somewhere i assume?

[favonia]

@Aiakio This is interesting. I'm aware that many devices and ISPs (incorrectly) block 1.1.1.1, but I didn't know some devices could (incorrectly) block both 1.1.1.1 and 1.0.0.1!

If you cannot change how your device works, you can use the experimental IP provider url:SOME_URL_HERE as a workaround. For example, IP4_PROVIDER=url:https://api4.ipify.org will make it work for IPv4. You have to use the edge tag instead of latest because I just implemented it. (You can switch back to latest after the next official release.) Let me know if you have questions about the workaround. Personally I suspect ipify is no longer actively maintained, but it's better than nothing.

[Aiakio]

Alright, let me first start off by saying...

        environment:
            - IP4_PROVIDER=url:https://api4.ipify.org
            - IP6_PROVIDER=url:https://api6.ipify.org

...works like a charm. Using the edge tag. Thank you so much! :)

=============== Now for the second part, i made some very strange observations.

I can ping and also tracert / traceroute 1.1.1.1 / 1.0.0.1 successfully on Windows and Linux (dual boot, one machine). But i cannot use a webbrowser to access 1.1.1.1 / 1.0.0.1. Not even through a VPN... A webbrowser (i tried different browsers) also times out. On both OS's. Exactly the same goes for the NAS.

It gets even stranger though: For some reason, i can access 1.1.1.1 / 1.0.0.1 through the browser on two phones (Android & Apple). All devices are on the same network. Phones and PC share the same WiFi and the NAS is on the same network via LAN.

So when i said

If i surf to 1.1.1.1 or 1.0.0.1 on a web browser, the page loads normally.

in the original post, i had only tested it through my phone, not the pc.

I have no clue whats going on with that.

EDIT: The only Browser that works so far to access 1.1.1.1 and 1.0.0.1 on PC is Tor Browser, lol. EDIT 2: I have a Mullvad Browser container connected to a gluetun vpn container (windscribe) and there i can also access 1.1.1.1...

[favonia]

@Aiakio It does sound very strange. I don't feel I can help you much in solving the mystery. Perhaps you should also try different browsers (e.g., Firefox, Chrome, etc.).

One thing you can help me about though is the format url:URL. Do you like how it's formatted? If you have any suggestions, please comment in https://github.com/favonia/cloudflare-ddns/issues/546 before I release the next version. Thanks!

[Aiakio]

I did try a lot of browsers, none worked, except the ones in my edits.

But yeah, you helped me out a lot already. Thanks to your tips on where to even start troubleshooting i found out a lot. And since Cloudflare DDNS is working now, i can take my time with figuring out why 1.1.1.1 is not working.

Thank you so much for taking the time to help me! Ill make sure to check out the other thread :)

[favonia]

@Aiakio Hi, the version with the url:URL feature has been officially released as 1.10.0. It is recommended to switch back to the latest tag because the edge tag is for me to try out experimental features. :sweat_smile:

[Aiakio]

Thank you for the notification. Will switch :)

[favonia]

@Aiakio This is a head-up---recent versions (1.13.0+) will benefit from an update to your configuration, and I am on the mission to eliminate the old template from this universe. In case you or anyone is confused by how to update the configuration, here's the tl;dr:

1. Remove cap_add: ... completely.
2. Add user: "1000:1000" (or other IDs you want to use).
3. Remove PUID=... and PGID=... (optional, but why not).

For more information, please see the CHANGELOG and README.

PS: the new template works for older versions of the updater as well!

[Aiakio]

Very kind of you to tag me. Thank you for the heads up. :)