DNS over TLS with CloudFlare not working for LAN hosts



  • Hello,

    I've followed this article: https://www.netgate.com/blog/dns-over-tls-with-pfsense.html and now none of the Windows or Linux machine on my 2 VLANs are able to perform DNS resolution.

    If I don't use the custom settings
    server:
    ssl-upstream: yes
    do-tcp: yes
    forward-zone:
    name: "."
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853

    Everything works fine, but IMHO it doesn't use TLS anymore.

    Any hint/idea would be greatly appreciated.

    Andy.



  • same trouble. It s look like pfsense dont agree with certificate



  • Thanks for confirming that I'm not the only one experiencing the issue.

    I wonder if Mr.  Ivor Kreso who wrote the official article is among the forum's readers/admins.



  • Seeing the same thing with 2.4.3-RELEASE.  Glad it's not just me.



  • Just tried this last night and it seemed to be working.  This morning, nothing on the internal network could do DNS resolution until I removed the custom settings and let it out over standard port 53.

    Wonder if something happened this morning to Cloudflare's DNS?



  • It wasn't working for me until I whitelisted 1.1.1.1 in pfBlockerNG.

    One of the lists (Abuse-Zeus) was blocking access to 1.1.1.1.

    Seems to be working now though.



  • Can confirm it's an issue for me too. Running pfSense 2.4.3. Not running pfBlocker.



  • A few of us appear to be having a similar issue and started a thread here with some error logs: https://forum.pfsense.org/index.php?topic=146207.0

    I'm guessing we're all experiencing the same problem.


  • Galactic Empire

    We're seeing it as well. While we're investigating this issue, it seems to work with quad9 so I suggest you try it.



  • @ivor:

    We're seeing it as well. While we're investigating this issue, it seems to work with quad9 so I suggest you try it.

    What changes need to be made to use quad9?


  • Galactic Empire

    We will be updating the blog post with that information, for now just replace the Cloudflare IP's with Quad9 ones (9.9.9.9 and 149.112.112.112).



  • @ivor:

    We will be updating the blog post with that information, for now just replace the Cloudflare IP's with Quad9 ones (9.9.9.9 and 149.112.112.112).

    Thanks. That worked.

    I’ve seen similar reports on other forums regarding cloudflare’s primary server not working. Hopefully whatever the issue is will get resolved soon.



  • Also had this issue with CloudFlare's DNS servers. Using Quad9 until someone can figure out what's going on.



  • Not that its needed but, same here. First thing this morning no DNS service. Quick fix but strange, worked well all day yesterday.

    Apr 4 09:28:42 unbound 15056:0 error: SSL_read syscall: Connection reset by peer


  • Galactic Empire

    We have updated the blog post with Quad9 settings https://www.netgate.com/blog/dns-over-tls-with-pfsense.html



  • @ivor:

    We will be updating the blog post with that information, for now just replace the Cloudflare IP's with Quad9 ones (9.9.9.9 and 149.112.112.112).

    Ivor, I see you've updated the instructions in the blog post to be closer to what I suggested here. However I still don't think you need the server: line.

    Also I suggest against recommending people mix and match DNS providers since that could result in inconsistent results as the various providers block different sets of phishing and malware sites.

    Finally it might be easier to confirm DNS over TLS is working by filtering States by :853 and :53.

    Thanks.


  • Rebel Alliance Developer Netgate

    You need the "server:" line because you cannot guarantee that the unbound config will still be in the "server:" context by the time it adds in the custom options. Depending on whatever else the user has configured in the resolver it may be in another section and break.



  • Good to know, thanks Jim.



  • Doesn't work well, for me anyway. I have DNSBL enabled and my options look like this:

    server:include: /var/unbound/pfb_dnsbl.*conf
    forward-zone:
    name: "."
    forward-ssl-upstream: yes
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853
    

    many websites don't load at all or very slow (some are ok), iOS Appstore won't work either.


  • Rebel Alliance Developer Netgate

    Cloudflare 's 1.1.1.1 server has been flaky for some people since it launched, try adding a line for 9.9.9.9 instead of 1.1.1.1



  • @T5000:

    Doesn't work well, for me anyway. I have DNSBL enabled and my options look like this:

    server:include: /var/unbound/pfb_dnsbl.*conf
    forward-zone:
    name: "."
    forward-ssl-upstream: yes
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853
    

    many websites don't load at all or very slow (some are ok), iOS Appstore won't work either.

    Cloudflare 1.1.1.1 and 1.0.0.1 is having issues with TLS atm. A Cloudflare team member mentioned that they will be releasing an update soon to correct it but there is no eta yet.

    Try the following:

    server:
    include: /var/unbound/pfb_dnsbl.*conf
    ssl-upstream: yes
    do-tcp: yes
    forward-zone:
    name: "."
    forward-addr: 9.9.9.9@853
    

    That's Quad9 for the moment… you can reverse back to Cloudflare DNS once the issue has been resolved.



  • Hi,

    Strange, when i use forward-addr: 9.9.9.9@853 is working, but when I change to forward-addr: 1.1.1.1@853 or forward-addr: 1.0.0.1@853 i lose my Internet.

    Any idea?

    Thanks


  • Rebel Alliance Developer Netgate

    Cloudflare has a problem with Unbound right now, they are not handling how it sends requests properly with tls. They say it's going to be fixed soon.



  • @jimp:

    Cloudflare has a problem with Unbound right now, they are not handling how it sends requests properly with tls. They say it's going to be fixed soon.

    Read on their Community this morning the update related to Unbound was released overnight. Testing here I still have an issue with 1.1.1.1 but 1.0.0.1 is fine. The issue covered here they created overnight a night ago with Unbound has been addressed though. No errors in my log. Now I just need to looking what is using 1.1.1.1 already.



  • I think they have solved it - it started working for me.



  • Yep, working for me now too.



  • For me resolution does not work always.
    I use MultiWAN with failover and it seems that if one gateway is down, resolution hangs.


Log in to reply