Enabling DNS SSL/TLS Local Client

[NollipfSense]

To enable DNS resolving via SSL/TLS for local client, all I need to do is check the box, pick the certificate for the local client...no need for firewall rule...correct?

[NollipfSense]

Well, it needs a bit more configuring per here: https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-config.html

However, even after doing all has required, I still get connection timeout; so, the problem could be FreePBX firewall...not sure what's going on. I find FreePBX to be finicky, indeed.

[NollipfSense]

So, I enabled DHCP static mapping, cleared the browser cache yet the freepbx domain name will not resolve locally. Then, I did a packer capture on port 853 while directing the browser to go to the address, nothing appeared when view capture, just empty, don't know what else to do...pfSense isn't doing anything either...any suggestions?

[NollipfSense]

So, no matter what DNS resolution behavior I set, whether use local (127.0.0.1), fall back to remote DNS or use local DNS, ignore remote DNS servers, local DNS always takes the longest and lands on the A record address instead on local IP address. I see why the browser would timeout with an error. Anyone knows why? Is it because of how domain zone was set up to point to the A record? Should I have a firewall rule to reject all other DNS request?

[johnpoz]

@nollipfsense your client asking on 53 udp going to be DoT? (dns over tls)?

That port would be 853.. Did you tell your client to use DoT and point it to pfsense? Does you client even support DoT?

Why would you think you would want or need to use DoT over your local network?

Not sure why anyone would want/need to do this.. But here using kdig which allows for easy testing of dot or doh sort of connections. I enabled unbound to listen on tcp 853, just using the same cert as my web gui, a cert I signed with my own ca..

Now I on my client I do a dot connection to pfsense on interface I am listening on, in this case 192.168.2.253 (yes this is allowed on the firewall rules on that interface).. You can see it validates the cert, and trusts it because I told it to use my CA cert.. And looks up www.google.com just fine.

But for the life of me can not figure out why you think your pbx needs to do dot locally?

[NollipfSense]

@johnpoz It seems that there are problems with the certificate...I get what appears half-right, half timeout so unable to verify. Not sure what all that means and why. I did a verification test from FreePBX CLI and it seems that I need to sort the problem out first:

openssl s_client -connect nollivoipserver.nollicomm.net:443...got:
depth=0 CN = nollivoipserver.nollicomm.net
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 CN = nollivoipserver.nollicomm.net
verify error:num=21:unable to verify the first certificate
verify return:1

Certificate chain
0 s:/CN=nollivoipserver.nollicomm.net
i:/C=US/O=Let's Encrypt/CN=R3

[johnpoz]

@nollipfsense I would think that is on your client then..

I don't have any problems validating connecting to my acme certs on pfsense (use them in haproxy)

user@NewUC:~$ openssl s_client -connect overseerr.snipped:443
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = overseerr.snipped
verify return:1
---
Certificate chain
 0 s:CN = overseerr.snipped
   i:C = US, O = Let's Encrypt, CN = R3
 1 s:C = US, O = Let's Encrypt, CN = R3
   i:C = US, O = Internet Security Research Group, CN = ISRG Root X1
 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---

None which has anything to do with your client doing a query on UDP 53 when your trying to do DoT which would be TCP over 853..

[NollipfSense]

@johnpoz said in Enabling DNS SSL/TLS Local Client:

I would think that is on your client then..

Yes John, it was the client, but also my fault. I forgot to paste the CA into FreePBX so that made it untrustworthy to pfSense which turned to the outside for resolving. It will take a few days to fix since it took me on a wild goose chase diagnosing while other work projects got neglected.

[NollipfSense]

Got it working finally, wipe off sweat...what was missing is that I also needed to add a host override and that cost me lots of time. I am amazed that it still used DNS:53...wow! Hey @johnpoz why it's use DNS:53 despite checking SSL/TLS and port 853?

[johnpoz]

@nollipfsense said in Enabling DNS SSL/TLS Local Client:

why it's use DNS:53 despite checking SSL/TLS and port 853?

You listening for dot on 853 has NOTHING to do with the client asking.. I find it hard to believe some pbx would even support dot.. And if it did - it would have to be setup to do that for sure..

[Gertjan]

@johnpoz said in Enabling DNS SSL/TLS Local Client:

why it's use DNS:53 despite checking SSL/TLS and port 853?

Who is "it" ?

When you set up a TLS web server on port 443, why is (was) everybody still using port 80 ?
Because clients do whatever they want !

With DNS, we can't redirect requests as we can do with web requests.

[2.6.0-RELEASE][admin@pfsense.local.net]/root: sockstat -4 | grep '853'
unbound  unbound    4826  5  udp4   *:853                 *:*
unbound  unbound    4826  6  tcp4   *:853                 *:*

so now Unbound is listening on port 53 and 853 (TLS). Like a webserver on port 80 and 443 (TLS).

This doesn't mean that my LAN devices start to use it. I have to inform - set up - them one by one so they are aware that they can use DNS over TLS over port 853.

[NollipfSense]

@johnpoz said in Enabling DNS SSL/TLS Local Client:

You listening for dot on 853 has NOTHING to do with the client asking..

I discovered why I was seeing that early this morning...my laptop is behind Mikrotik...Thanks John.

[NollipfSense]

@gertjan said in Enabling DNS SSL/TLS Local Client:

When you set up a TLS web server on port 443, why is (was) everybody still using port 80 ?
Because clients do whatever they want !

Thank you Gertjan, I discovered that early this morning.