Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Cloudflare new DNS 1.1.1.1 issues

    Scheduled Pinned Locked Moved General pfSense Questions
    16 Posts 8 Posters 4.2k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • D
      ddg00101
      last edited by

      Hi guys.

      For some reason my network appliance running pfsense 2.4.3 refuses to access 1.1.1.1. Trying directly from my modem works fine however. I have tried toggling bogon network blocking off on the wan interface with no luck.

      My attempts to reach 1.1.1.1 were also initiated directly from pfsense on the WAN interface. Any help or ideas would be appreciated.

      1 Reply Last reply Reply Quote 0
      • KOMK
        KOM
        last edited by

        Do you use pfBlockerNG?

        https://www.reddit.com/r/PFSENSE/comments/88wg6g/issue_with_pfblockerng_dnsbl_and_cloudflares_1111/

        1 Reply Last reply Reply Quote 0
        • stephenw10S
          stephenw10 Netgate Administrator
          last edited by

          What actual error do you see when you try to ping it?

          Steve

          1 Reply Last reply Reply Quote 0
          • J
            jaspras
            last edited by

            nslookup google.com 1.1.1.1 from your PC
            From cmd or ssh in case of *nix OS

            Do you get IP addresses back?
            If you do

            Do the same from pfsense ssh
            Do you get IP addresses back?

            No?

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              Given there is a known issue with pfBlocker if you're running DNS-BL that's the first place to check. See KOM's link above.

              If it is that just set the list action to disabled in 'DNSBL IP Firewall Rule Settings' until a package update is available.

              Steve

              Selection_375.png
              Selection_375.png_thumb

              1 Reply Last reply Reply Quote 0
              • D
                ddg00101
                last edited by

                So, I had the pfblocker package installed, but had never used it.

                Removing the package did not fix the issue. I am going to try re-installing it and disabling the list in question as KOM linked to.

                As per another comment from jaspras:
                From desktop-

                nslookup google.com 1.1.1.1
                DNS request timed out.
                    timeout was 2 seconds.
                Server:  UnKnown
                Address:  1.1.1.1

                DNS request timed out.
                    timeout was 2 seconds.
                DNS request timed out.
                    timeout was 2 seconds.
                DNS request timed out.
                    timeout was 2 seconds.
                DNS request timed out.
                    timeout was 2 seconds.
                *** Request to UnKnown timed-out

                from pfsense shell-

                nslookup google.com 1.1.1.1
                ;; connection timed out; no servers could be reached

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Well something is preventing that then. Do you have anything odd in your routing table?

                  If you run a pcap on WAN and filter for 1.1.1.1 do you actually see packets leaving why you try to nslookup against it from the command line.

                  Steve

                  1 Reply Last reply Reply Quote 0
                  • D
                    ddg00101
                    last edited by

                    I don't see anything odd in the routes unless someone else does:

                    Sanitized output of course….. assume valid address for the Xs

                    netstat -rn
                    Routing tables

                    Internet:
                    Destination        Gateway            Flags    Netif Expire
                    default            99.74.X.X        UGS        em0
                    8.8.8.8            99.74.X.X        UGHS        em0
                    10.0.2.0/24        10.0.2.2          UGS      ovpns1
                    10.0.2.1          link#7            UHS        lo0
                    10.0.2.2          link#7            UH      ovpns1
                    10.0.3.0/24        10.0.3.2          UGS      ovpns2
                    10.0.3.1          link#8            UHS        lo0
                    10.0.3.2          link#8            UH      ovpns2
                    99.74.X.0/22    link#1            U          em0
                    99.74.X.X      link#1            UHS        lo0
                    127.0.0.1          link#3            UH          lo0
                    192.168.1.0/24    link#2            U          em1
                    192.168.1.1        link#2            UHS        lo0

                    Internet6:
                    Destination                      Gateway                      Flags    Netif Expire
                    default                          fe80::e222:4ff:fe16:4915%em0  UGS        em0
                    ::1                              link#3                        UH          lo0
                    2001:4860:4860::8888              fe80::e222:4ff:fe16:4915      UGHS        em0
                    2600:1700:2d60:XXXX::/64          link#1                        U          em0
                    2600:1700:2d60:XXXX::469          link#1                        UHS        lo0
                    2600:1700:2d60:XXXX:215:17ff:fea9:XXXX link#1                  UHS        lo0
                    2600:1700:2d60:XXXX::/64          link#2                        U          em1
                    2600:1700:2d60:XXXX:215:17ff:fea9:XXXX link#2                  UHS        lo0
                    fe80::e222:4ff:fe16:4915          fe80::e222:4ff:fe16:4915%em0  UGHS        em0
                    fe80::%em0/64                    link#1                        U          em0
                    fe80::215:17ff:fea9:ff54%em0      link#1                        UHS        lo0
                    fe80::%em1/64                    link#2                        U          em1
                    fe80::1:1%em1                    link#2                        UHS        lo0
                    fe80::%lo0/64                    link#3                        U          lo0
                    fe80::1%lo0                      link#3                        UHS        lo0
                    fe80::%ovpns1/64                  link#7                        U        ovpns1
                    fe80::215:17ff:fea9:XXXX%ovpns1  link#7                        UHS        lo0
                    fe80::%ovpns2/64                  link#8                        U        ovpns2
                    fe80::215:17ff:fea9:XXXX%ovpns2  link#8                        UHS        lo0

                    1 Reply Last reply Reply Quote 0
                    • R
                      revengineer
                      last edited by

                      I can ping and use nslookup with 1.1.1.1. I have pfBlocker with DNSBL, snort, and squidguard running. So it seems to be an isolated issue.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Mmm, something odd. Try the pcap whilst nslookup-ing. Or least check for states to 1.1.1.1 open on WAN. Maybe the upstream device is blocking it although it can connect itself.

                        Steve

                        1 Reply Last reply Reply Quote 0
                        • D
                          ddg00101
                          last edited by

                          Here is the relevant pcap:

                          no.         time         source dest       proto length info
                          1702 6.019781         99.74.X.X 1.1.1.1 DNS 80 Standard query 0x0001 PTR 1.1.1.1.in-addr.arpa
                          2695 12.024627 99.74.X.X 1.1.1.1 DNS 70 Standard query 0x0004 A google.com
                          2915 14.026166 99.74.X.X 1.1.1.1 DNS 70 Standard query 0x0005 AAAA google.com

                          It is a stupid ATT gateway that is in DMZ mode, though I may have to dig into it and see if it is doing something screwy too.

                          1 Reply Last reply Reply Quote 0
                          • N
                            Napsterbater
                            last edited by

                            @ddg00101:

                            It is a stupid ATT gateway that is in DMZ mode, though I may have to dig into it and see if it is doing something screwy too.

                            At Least 2 AT&T Gateways use 1.1.1.1 and/or 1.0.0.1 or the blocks they are in for themselves, thus break routing to them.

                            5268ac Breaks connectivity to 1.1.1.1, though 1.0.0.1 is fine.
                            BGW210 apparently breaks both.

                            1 Reply Last reply Reply Quote 0
                            • D
                              ddg00101
                              last edited by

                              Oh FFS, 1.0.0.1 does work, so is very likely what you just mentioned. No idea why I didn't think to try the backup address. I really loath ATT, but only fiber option here. I think that just explained everything and fixes my issue.

                              Thanks so much.

                              1 Reply Last reply Reply Quote 0
                              • T
                                Tantamount
                                last edited by

                                Is it even worth switching anyway?

                                8.8.8.8 or 1.1.1.1 – it's all still clear text, so there are very little privacy differences between the two.  This only takes away information from Google -- a company that can use these queries to know which sites are more relevant than others -- i.e. give you better search results.

                                There's also the problem introduced by using these "proxy" DNS servers.  By running your own DNS server, when you do a query, the DNS servers it queries can respond based on your IP address -- this means the other DNS servers have the potential to return IP addresses that are closer to you.  When you query using these hosted DNS servers, you have the potential to get cached results that someone before you made that may not be ideal for your location. This means gaming and other services where you want the lowest latency possible may suffer.

                                I ran into an issue using blacklists for spam filtering a while back --- it wasn't working reliably.  I found out that the blacklisting mechanism works by performing DNS queries -- and that the blacklisting service limits the number of queries based on the DNS server doing the asking.  So if you use these DNS hosting servers, you're much more likely to reach their cap because a LOT of people use them.  Once I started using my own DNS server, that problem vanished.

                                1 Reply Last reply Reply Quote 0
                                • N
                                  Napsterbater
                                  last edited by

                                  @Tantamount:

                                  Is it even worth switching anyway?

                                  8.8.8.8 or 1.1.1.1 – it's all still clear text, so there are very little privacy differences between the two.  This only takes away information from Google -- a company that can use these queries to know which sites are more relevant than others -- i.e. give you better search results.

                                  There's also the problem introduced by using these "proxy" DNS servers.  By running your own DNS server, when you do a query, the DNS servers it queries can respond based on your IP address -- this means the other DNS servers have the potential to return IP addresses that are closer to you.  When you query using these hosted DNS servers, you have the potential to get cached results that someone before you made that may not be ideal for your location. This means gaming and other services where you want the lowest latency possible may suffer.

                                  I ran into an issue using blacklists for spam filtering a while back --- it wasn't working reliably.  I found out that the blacklisting mechanism works by performing DNS queries -- and that the blacklisting service limits the number of queries based on the DNS server doing the asking.  So if you use these DNS hosting servers, you're much more likely to reach their cap because a LOT of people use them.  Once I started using my own DNS server, that problem vanished.

                                  1.1.1.1 offers DNS over TLS and DNS over HTTPs
                                  8.8.8.8 only offers DNS over HTTPs,

                                  So not necessarily plain text, and DNS over TLS is easy to do on pfSense wifh BIND and sTunnel

                                  Also EDNS Client Subnet solves the issue of DNS based geolocation, wich i believe both support.

                                  1 Reply Last reply Reply Quote 0
                                  • GPz1100G
                                    GPz1100
                                    last edited by

                                    In case you haven't figured it out yet, firmware 1.5.11 (1.5.12?) breaks access to 1.1.1.1.  This ip is now some sort of internal ip within the gateway (bgw210).

                                    1 Reply Last reply Reply Quote 0
                                    • First post
                                      Last post
                                    Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.