Skip to content
Geek is the Way!
Menu
  • Forums
  • Sobre o blog
  • Contato
  • English
    • Português
Menu

Protect your DNS requests using pfSense

Posted on June 21, 2020August 16, 2022 by Thiago Crepaldi

Last Updated on August 16, 2022 by Thiago Crepaldi

Configuring pfSense DNS Resolver

Many ISPs or other Internet service providers collect information for commercial reasons (selling your profile for directed advertisement) or otherwise. pfSense allows you to use DNS with TLS to encrypt your request in a way that only you and the DNS provider can see it.

DNS over TLS is not supported by all DNS providers, so in this post I will use CloudFlare, which is free, fast, support TLS and don’t keep logs. Visit https://1.1.1.1/dns/ for more information

On your pfSense dashboard page, click on System >> General Setup menu. At the DNS Server Settings tab, add 1.1.1.1 and 1.0.0.1 as DNS servers. For most cases, you don’t need to type anything for Hostname and Gateway. Uncheck the DNS Server Override check box to make sure your ISP will not override your preference. Complete the process by clicking Save at the bottom.

Now that your DNS is configured, let’s make sure we enable TLS on it. Click on Services >> DNS Resolver menu. Make sure Enable checkbox is checked and then check the following checkbox too:

  • DNSSEC: Enable DNSSEC support
  • DNS Query Forwarding: Enable Forwarding Mode
  • DNS Query Forwarding: Use SSL/TLS for outgoing DNS Queries to Forwarding Servers

Click Save and Apply changes and you should be good to go. Sometimes settings are not applied correctly and a full reboot is needed (Diagnostics >> Reboot)

Some devices have hard coded DNS Servers on them, so they will use them instead of pfSense. To fix that, you can block external DNS Servers and/or redirect them to pfSense through Firewall rules.

Redirecting all DNS Requests to pfSense

The following instructions are originally published at https://docs.netgate.com/pfsense/en/latest/dns/redirecting-all-dns-requests-to-pfsense.html, but I will replicate them here too.

Before adding this rule, ensure the DNS Forwarder or DNS Resolver is configured to bind and answer queries on localhost, or All interfaces.

In the following example, the LAN interface is used, but it could be used for any local interface. Change the Interface and Destination as needed.

  • Navigate to Firewall > NAT, Port Forward tab
  • Click Add to create a new rule
  • Fill in the following fields on the port forward rule:
    • Interface: LAN
    • Protocol: TCP/UDP
    • Destination: Invert Match checked, LAN Address
    • Destination Port Range: 53 (DNS)
    • Redirect Target IP: 127.0.0.1
    • Redirect Target Port: 53 (DNS)
    • Description: Redirect DNS
    • NAT Reflection: Disable

Any DNS request made to any external IP address will result in the query being answered by the firewall itself. Access to other DNS servers on port 53 is impossible.

Blocking DNS Queries to External Resolvers

The following instructions are originally published at https://docs.netgate.com/pfsense/en/latest/dns/blocking-dns-queries-to-external-resolvers.html, but I will replicate them here too

  1. Add a firewall rule on Firewall >> Rules, LAN tab allowing protocol TCP/UDP, source: any, destination: LAN Address, destination port range: 53
  2. Move this newly created rule from step #1 to the very top of the LAN rules
  3. Add a new rule blocking protocol TCP/UDP, source: any, destination: any, destination port range: 53
  4. Move the rule created in step #3 to the second position behind the permit rule that was moved in step #2.
  5. Save and Apply changes

If you followed the steps for redirecting all DNS requests to your local pfSense, ensure the rule to pass DNS to 127.0.0.1 is above any rule that blocks DNS!

Blocking other DNS over TLS servers

It is safer to have a single DNS server running on your network, so let’s add one more firewall rule to block any connection for any DoT other than your pfSense.

  1. Add a firewall rule on Firewall >> Rules, LAN tab blocking TCP protocol, Source: any, Destination any, Destination port range 853
  2. Move this newly created rule from step #1 to the very top of the LAN rules
  3. Save and Apply changes

Verify everything works

I have tried using 1.1.1.1/help to see whether my settings were working, but found out that when DNSSEC is enabled on pfSense, CloudFlare’s test fails, but it is actually working. To verify your settings, go to Diagnostics >> State, select all interfaces and set Filter Expression as your DNS IP. You should see that the only connections on port 53 are for your localhost and all other connections to your DNS are over port 853, the DNS over TLS port.

Another test is capturing some packages through Diagnostics >> Packet capture page. Set the Interface as WAN and Port as 853. Click on Start button and use your browser to visit some pages, such as pfsense.org. Stop and View capture. You should see several packages flowing from/to 1.1.1.1:853. Repeat the capture for port 53 and note that the capture will be empty.

Visit https://dnssec.vs.uni-due.de and click Start test. If you get a thumbs up, your DNS is safe!

Share this:

  • Tweet

Related

4 thoughts on “Protect your DNS requests using pfSense”

  1. Jake says:
    February 13, 2021 at 11:54 PM

    You mention enabling DNSSEC support under Services >> DNS Resolver, but that won’t do much good if you are in forwarding mode. You should be relying on the forwarding server to perform the DNSSEC validation, so there is no need to do this check (again) in Unbound/PFsense. You could, but I don’t see a point unless you don’t trust the forwarding server (in which case, why use it?) That also means you won’t need to harden DNSSEC data under Services >> DNS Resolver >> Advanced Settings.

    Reply
  2. Thiago Crepaldi says:
    February 15, 2021 at 1:24 PM

    Hey there, thanks for the discussion. If DNSSEC is not enforced, isn’t there a chance someone could alter the content of the response and corrupt whatever content the forwarding servers returned? It is not a matter of not trusting the forwarding server, but not trusting the media in which servers communicate through

    Reply
  3. Jake says:
    February 18, 2021 at 9:25 PM

    In forwarding mode you loose the end to end validation, since you do not independently talk to each NS server in the chain down from roots to get to the authoritative server. Instead you are trusting the DNS forwarding server to get this information for you and provide the validated response back. In your example all someone would need to do is not send back the DNSSEC info and pfSense/unbound would interpret that as DNSSEC isn’t enabled for the domain and pass the record on to the client as valid. DNSSEC enabled in pfSense/unbound wouldn’t prevent this scenario from happening in forwarding mode as all DNSSEC is doing is validation that the a record in a domain has been signed by the owner of the domain, which is done from the information in the DNS reply it receives back.

    Reply
  4. Pingback: Isolating Wi-Fi networks using VLAN subnets through pfSense + UDM-Pro and a little more... - Geek is the Way!

Leave a ReplyCancel reply

LIKED? SUPPORT IT :)

Buy Me a Coffee


Search


Categories

  • Cooking (1)
  • Homelab (79)
    • APC UPS (6)
    • pfSense (40)
    • Proxmox (20)
    • Shopping (1)
    • Supermicro (2)
    • Synology NAS (8)
    • Ubiquiti (6)
    • UDM-Pro (4)
  • Random (3)
  • Wordpress (1)

Tags

Agentless monitoring (3) AP9631 (3) Apache2 (3) APC UPS (6) Bind9 (3) certificates (5) cron (2) DDNS (5) debian (3) DNS (7) DSM (6) Dynamic DNS (4) Firewall (9) gmail (3) IPSEC (2) Let's Encrypt Certificates (7) monitoring (18) networking (21) PBS (3) pfBlockerNG (2) pfsense (43) port forwarding (3) proxmox (17) proxmox backup server (3) proxmox community (2) proxmox virtual environment (16) pve (5) rev202207eng (76) routing (2) security (28) SNMP (4) SNMPv1 (3) ssh (4) SSL (6) Synology (7) udm-pro (5) unifi (6) unifi controller (3) Unifi Dream Router (2) UPS (5) VLAN (4) vpn (9) wifi (4) Zabbix (18) Zabbix Agent2 (11)

See also

Privacy policy

Sitemap

©2025 Geek is the Way! | Design by Superb