The website is not displayed, even though it is allowed on the PFSense side.

Yet_learningPFSense

@stephenw10 Thank you. I received a reply from the QubesOS forum just now. It seems that the problem was in the DNS address, 1.0.0.2 and 1.1.1.2 are CloufFlare addresses but with anti-malware functionality, so I changed this one to 1.1.1.1/1.0.0.1 and changed all other settings back and now I can connect to the internet again! I don't know why 1.0.0.2 and 1.1.1.2 got DNS Probe errors, but I'm glad things are back to normal for now.

192.168.1.1 is the LAN address for the PFSense (there is also another 192.168.2.1 which I can get into the admin panel but the internet is blocked). . The client device is 192.168.1.1/24 and the QubesOS PC is connected to this subnet. Yes, when I added 9.9.9.9, communication was possible, so that's when I realised that there was a problem with the address itself.

I tried reverting to 1.0.0.2 and 1.1.1.2, which had the problem, and did the DNS Lookup that you told me about, but it seems to be communicating. This problem is a real mystery, the FW logs show that communication is working as shown in the image, but there is no internet communication, so if you have any ideas, I would like to know them.

alt text

stephenw10

If you're setting those DNS servers in QubesOS directly pfSense doesn't really come into it. It just passes that traffic like it would for anything else.

johnpoz

@Yet_learningPFSense said in The website is not displayed, even though it is allowed on the PFSense side.:

a problem with the DoH/DoT of the PFSense

Do those other IPs you were using for cloudflare support dot? if your trying to do dot to something and it doesn't support it then yeah its not going to work ;)

Notice 1.0.0.2 and 1.1.1.2 are not doing dot.. Seems like they are listening, but the cert they send back is not setup for those SAN ips..

So for example if I ask them over tls (dot) but say don't validate the cert

Here is what I show for their SANs on 1.1.1.2 on 853

Also could be that if they do malware filtering - what you were asking for was blocked by them..

Yet_learningPFSense

@stephenw10 Thanks. There was an "Additional DNS" field in the connection settings, so the reason why we couldn't communicate even though we had another 9.9.9.9 set here was because the nameserver in resolv.conf was given first priority. nameserver was set to 9.9.9.9 or 1.1.1.1. communication was possible. Then, after changing the DNS on the PFSense side to 1.1.1.1, it was good that communication was possible even after changing the nameserver back to the original one. Then I changed it back to 1.0.0.2 and 1.1.1.2 again and it was able to communicate as it was.

I don't go to dangerous sites, but when I went to see a few adult sites, QubesOS blocked access to 1.0.0.2? I think QubesOS has some clever IPS features, but if I think that dom0 has been hijacked, this makes sense, but I don't think hackers can break through the robustness of QubesOS (I have followed the precautions for use).

But anyway, it was a great help to be able to communicate with the internet. I would like to install dig on a Debian11 virtual OS in some way and see what logs come back when the same problem occurs again.

Yet_learningPFSense

@johnpoz Thanks for the verification together. I reviewed it a few times and understood that the hostname validation is not done on 1.0.0.2 and 1.1.1.2. On my end, PFSense is communicating at 853, but the hostname validation is not done(i think too), which may have caused the problem. But now I've reverted back to 1.0.0.2 and 1.1.1.2 and I'm still able to communicate, I don't think CloudFlare has changed their specifications, and if so, I will probably lose internet connection again in a few days. I will install the dig command for that time.

! alt text

johnpoz

@Yet_learningPFSense I normally do not do dot from pfsense. But not doing validation of the certs is pretty big deal when it comes to using dot or doh..

if your not validating who your talking to - then in theory its possible for you dns queries to be redirected..

I think unbound can not do validation if you have don't have a fqdn listed.. But that is pretty much a borked setup for dot or doh in general.. You should be putting in a name in your dns setup of say cloudflare-dns.com which would validate and you would know your talking to cloudflare dns..

Yet_learningPFSense

@johnpoz Thanks. I knew about the image you gave me and also the problem caused by the hostname not being validated, so I reverted to 1.1.1.1 and 1.0.0.1 and also set the hostname to 1dot1dot1dot1.cloudflare.com for validation. -dns.com to be set. Another security improvement , thank you very much.

johnpoz

@Yet_learningPFSense said in The website is not displayed, even though it is allowed on the PFSense side.:

1dot1dot1dot1.cloudflare.com

that is not really valid but would be covered by the wildcard..

Yet_learningPFSense

It seems that @johnpoz DeepL was used and the description failed (just 1dot1dot1dot1.cloudflare-dns.com). Hmm, with wildcards, ".cloudflare.com" and ".cloudflare-dns.com" both gave errors and could not be set. It seems that I have to use the full address to describe it, but how should I place the wildcard?

johnpoz

@Yet_learningPFSense said in The website is not displayed, even though it is allowed on the PFSense side.:

".cloudflare.com" and ".cloudflare-dns.com"

Not sure where you got those from?

Use the fqdn cloudflare-dns.com or since there is a wild card for cloudflare-dns.com you could use say dns.cloudflare-dns.com

Or you could use the fqdn one.one.one.one for example..

Gertjan

@Yet_learningPFSense

1do1 what ? where ? why ?

edit : "getting back to 1.0.0.2 doesn't work"

According to the source : https://developers.cloudflare.com/1.1.1.1/setup/

You should use "security.cloudflare-dns.com" as the host name and that's it.
"security.cloudflare-dns.com" points to, of course : 1.0.0.2 and 1.1.1.2 - these are the two "Block malware" DNS servers, to be contacted over port '853' - TCP only ( ! )

So :

and then :

and done.

The pfSense initiated TLS connection to 1.0.0.2 and 1.1.1.2 will ask for a cert, and this cert will tell "I"m am "security.cloudflare-dns.com" so pfSense, unbound, knows that the connection is 'ok'.

@johnpoz : Where can I get that doggo (dig on PC ?!) tool ?

Yet_learningPFSense

@johnpoz Get the hostname here.
https://blog.cloudflare.com/ja-jp/enable-private-dns-with-1-1-1-1-on-android-9-pie-ja-jp/

I was under the impression that you were using wildcards and that you were supposed to write something like *.dns.cloudflare-dns.com. Once again, we have revised it to "dns.cloudflare-dns.com" by removing the 1dot~.

johnpoz

@Gertjan said in The website is not displayed, even though it is allowed on the PFSense side.:

Where can I get that doggo (dig on PC ?!) tool ?

Yeah like that huh ;) hehehe

https://github.com/mr-karan/doggo

Had been using kdig, but was tooling around for other tools, and ran across it - its pretty robust in what it can do..

I found this one too which isn't bad either

https://github.com/ameshkov/dnslookup

if I recall - what I was looking for was a tool that could do quic and one of them had a problem with it, or maybe it was kdig didn't support it or output what I wanted.. But yeah found 2 new tools that work pretty slick on windows even.

Yet_learningPFSense

@Gertjan My screen looks a little different, but I set it up this way and completed successfully. The 1dot~ address is the one I was trying to get from here. It seems it was actually a different one... https://blog.cloudflare.com/ja-jp/enable-private-dns-with-1-1-1-1-on-android-9-pie-ja-jp/

! alt text