Rule to block DNS except pfSense and cloudflare

Inxsible

I use the pfSense DNS Resolver as the only DNS on my network. I had the following rule to allow LAN Net to query pfSense for DNS and the second row to block all other DNS

Protocol	Source	Port	Destination	Port	          Gateway	Description
IPv4 UDP  *             *       LAN Net           53(DNS)     *               Allow DNS to pfSense
IPv4 UDP  LAN Net *        *                      53(DNS)     *                Block all other DNS

and this used to work fine for me.

But recently I created a caddy2 server as a reverse proxy for the various services that I self-host. While doing that, I thought it would be good to use LetsEncrpyt certs as well since caddy has the built in automation for it. I use cloudflare as the DNS for my external domain because, well, caddy has a cloudflare plugin available.

Due to the Block rule, caddy was not able to successfully test the DNS challenge for LetsEncrypt. Once I disabled the Block rule, everything works as expected.

How should I now block all the other DNS queries except the ones to my pfSense and also the 2 name servers that have been assigned to me in Cloudflare?

I tried using the IP address for both the Cloudflare name servers, but found out real quick that their IPs change frequently-- so that's not a solution. Also I couldn't use the domain name of the name servers because when choosing Single host or IP address in the block rule -- it requires it to be an IP address.

Any pointers would be really helpful.

Thanks,
Inxsible

Gertjan

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

I use the pfSense DNS Resolver

The resolver will check for DS records. It's all about DNSSEC. If these exist, the entire initial DNS request will get validated. The records that are coming in now can be to big for UDP. Normally, not an issue, but you decided that DNS is UDP only. Why ?

Depending on what type of domain name validation method you chose, the verification protocol of Letenscrypt can also produce DNS TCP traffic (I didin't check / tested this myself although I'm using the default nsupdate method, I'm using my own remote 'bind' master and salve domain name servers).

Inxsible

@Gertjan said in Rule to block DNS except pfSense and cloudflare:

The resolver will check for DS records. It's all about DNSSEC. If these exist, the entire initial DNS request will get validated. The records that are coming in now can be to big for UDP. Normally, not an issue, but you decided that DNS is UDP only. Why ?

Not entirely sure what you mean there. Are you saying I should make sure that DNSSEC is disabled? Where would I do that in pfSense?

@Gertjan said in Rule to block DNS except pfSense and cloudflare:

Depending on what type of domain name validation method you chose, the verification protocol of Letenscrypt can also produce DNS TCP traffic (I didin't check / tested this myself although I'm using the default nsupdate method,

I am using the DNS challenge because all of these services are internal to my LAN and not available to the outside world.

Gertjan

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

Not entirely sure what you mean there. Are you saying I should make sure that DNSSEC is disabled? Where would I do that in pfSense?

pfSense ?
Nothing. Without DNSSEC, the resolver - DNS - will work, "the old fashioned way".
The real question is : what does DNSSEC offer you ?
Using DNSSEC will need "DNS" to work with UDP - the old way - and TCP, as UDP only won't handle the job anymore.

Btw : when forwarding, stop using DNSSEC as it makes no sense.

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

I am using the DNS challenge because all of these services are internal to my LAN and not available to the outside worl

Again : are you sure DNS only uses UDP ? Include TCP.

JeGr

First thing:

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

IPv4 UDP * * LAN Net 53(DNS) * Allow DNS to pfSense

as @Gertjan said: change UDP to UDP/TCP as DNS can also be TCP based on payload. So you're not allowing TCP, that may be why Caddy is failing in the first place.

Second: check your server that you run caddy. Does it really use pfSense as DNS? Check resolve.conf etc. and make sure it does. Also does Caddy perhaps use it's own DNS resolving method that tries to check directly with an upstream DNS server (what you are blocking)? I'd simply check my firewall logs when Caddy is running those Acme checks and verify, that it really uses pfSense to resolve DNS. If not it's no wonder that it fails the DNS check.

Otherwise you could also exclude the Caddy server from being blocked and make an exception above the block rule to allow source <caddy_server_ip> to use DNS where it wants to.
I'd think about just removing the blocking rule and changing it to a "redirect all to pfSense" - that may work as well (just rewrite all DNS packages to go to pfSense' DNS resolver anyway instead of forwarding them outside).

Cheers
\jens

NogBadTheBad

Wouldn't it be easier to force all the clients to use pfSense for DNS regardless of their setting, then set pfSense to use Cloudflare ?

https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html

Gertjan

Easier ? Sure.
Will it always work out well ? Noop.
It could break Caddy's DNS.
What if Caddy was using Cloudfare also, using TLS DNS, and using the domain name, not the IP, so the cert will get verified and break because redirecting (forcing) to pfSense will fail the TLS.

Btw : using a device on my own network that doesn't permit me to control it's basic network behaviour makes it .... never to the list "items to buy".

Inxsible

@JeGr said in Rule to block DNS except pfSense and cloudflare:

as @Gertjan said: change UDP to UDP/TCP as DNS can also be TCP based on payload. So you're not allowing TCP, that may be why Caddy is failing in the first place.

I changed it to TCP/UDP and re-enabled the Block rule. But caddy was not able to get the certs.

Aug 28 15:27:16 reverseproxy caddy[19770]: 2020/08/28 15:27:16 [INFO] [home.domain.com] acme: Waiting for DNS record propagation.
Aug 28 15:27:28 reverseproxy caddy[19770]: 2020/08/28 15:27:28 [INFO] [home.domain.com] acme: Waiting for DNS record propagation.
Aug 28 15:27:30 reverseproxy caddy[19770]: 2020/08/28 15:27:30 [INFO] [home.domain.com] acme: Cleaning DNS-01 challenge
Aug 28 15:27:31 reverseproxy caddy[19770]: 2020/08/28 15:27:31 [INFO] Deactivating auth: https://acme-v02.api.letsencrypt.org/acme/authz-v3/6830225820
Aug 28 15:27:31 reverseproxy caddy[19770]: 2020/08/28 15:27:31 [ERROR] error: one or more domains had a problem:
Aug 28 15:27:31 reverseproxy caddy[19770]: [home.domain.com] time limit exceeded: last error: read udp 192.168.1.27:44198->172.34.98.54:53: i/o timeout
Aug 28 15:27:31 reverseproxy caddy[19770]:  (challenge=dns-01 remaining=[])
Aug 28 15:27:33 reverseproxy caddy[19770]: 2020/08/28 15:27:33 [ERROR] attempt 1: [home.domain.com] Obtain: [home.domain.com] error: one or more domains had a problem:
Aug 28 15:27:33 reverseproxy caddy[19770]: [home.domain.com] time limit exceeded: last error: read udp 192.168.1.27:44198->172.34.98.54:53: i/o timeout
Aug 28 15:27:33 reverseproxy caddy[19770]:  - retrying in 1m0s (1m4.402930884s/720h0m0s elapsed)...

@JeGr said in Rule to block DNS except pfSense and cloudflare:

Second: check your server that you run caddy. Does it really use pfSense as DNS? Check resolve.conf etc. and make sure it does.

I checked and the only nameserver defined in the resolv.conf is the ip for the pfSense

@JeGr said in Rule to block DNS except pfSense and cloudflare:

Also does Caddy perhaps use it's own DNS resolving method that tries to check directly with an upstream DNS server (what you are blocking)?

Caddy 2 has some DNS plugins -- Cloudflare being one of them where you can define the API token for your Cloudflare account and then LetsEncrypt then uses that token to perform the DNS challenge. In the process it also creates TXT records when checking if you actually own the domain name.

I don't know how I can instruct Caddy to use the local pfSense as the DNS -- Wouldn't it still need an external domain for LetsEncrypt to issue a certificate?

I think my last option is to allow the caddy server's ip to go whereever it feels like for DNS.

Inxsible

@NogBadTheBad said in Rule to block DNS except pfSense and cloudflare:

Wouldn't it be easier to force all the clients to use pfSense for DNS regardless of their setting, then set pfSense to use Cloudflare ?

https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html

I am looking into this now. Thanks. Will see if this does what I want.

Gertjan

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

192.168.1.27:44198->172.34.98.54:53

Who is this 172.34.98.54 ? It should be a (slave) DNS name server of your domain ?
You should be able to

dig @172.34.98.54 your-domaine.tld

and even, during acme cert update, able to 'see' the TXT record (the token) :

dig  @172.34.98.54 _acme-challenge.your-domain.tld

This token should be visible on any master and slave DNS domain name server.

You should probably give the DNS slave(s) domain server(s) more time to sync up with the master DNS.
Note : the ACME script updates the master with whatever method you choose. It's then up to the master so 'signal' the slaves that an update for the "name zone" is available. The slaves come in after 'some time' to sync up. This time is purely random, and most often totally out of your control.
Letenscrypt testing should be done after this delay. The DNS zone record tested, TXT field in the subdomain "_acme-challenge" in any of your DNS name servers.
Note : from what I understood, these days, Letenscrypt test ALL DNS domain name servers. So, they better have synced up all of them.
Some slaves are set up to sync in seconds, other can take minutes to do So I even saw hours ....

ericjames

This post is deleted!

ericjames

@Inxsible Contingent upon what sort of space name approval strategy you picked, the confirmation convention of Letenscrypt can likewise deliver DNS TCP traffic I didin't check/tried this myself despite the fact that I'm utilizing the default nsupdate technique, I'm utilizing my own far off 'tie' ace and treatment area name workers.

Inxsible

@ericjames said in Rule to block DNS except pfSense and cloudflare:

I didin't check/tried this myself despite the fact that I'm utilizing the default nsupdate technique, I'm utilizing my own far off 'tie' ace and treatment area name workers.

Can you please explain this like you were explaining a total noob?

Raffi_

@Inxsible said in Rule to block DNS except pfSense and cloudflare:

@ericjames said in Rule to block DNS except pfSense and cloudflare:

I didin't check/tried this myself despite the fact that I'm utilizing the default nsupdate technique, I'm utilizing my own far off 'tie' ace and treatment area name workers.

Can you please explain this like you were explaining a total noob?

Pretty sure that's a bot or spammer. A total of two posts by that account. First one was deleted and the second one makes no sense to even non noobs. It's gibberish.

Edit, I can confirm the steps for redirecting DNS posted further above will work, I recently set that up.