Differences

This shows you the differences between two versions of the page.

--- pfsense:pfblockerng:selectively_enforcing_pfblockerng_for_specific_clients_or_networks [2020/11/29 12:18] – peter
+++ pfsense:pfblockerng:selectively_enforcing_pfblockerng_for_specific_clients_or_networks [2021/01/06 10:06] (current) – [Basic Example] peter
@@ Line 1: / Line 1: @@
 ====== PFSense - pfBlockerNG - Selectively enforcing pfBlockerNG for specific clients or networks ======
+<WRAP alert>
+**ALERT:**  Stopping the services associated with pfblockerNG (pfb_dnsbl & pfb_filter) while Unbound / DNS Resolver is running will cause crazy things to happen, including breaking the DNS Resolver service on your device temporarily.
+**Don’t do this!**
+Instead, first remove any custom options you’ve implemented with this guide to do with pfBlockerNG from your **DNS Resolver Custom Options** field.
+Then in **Firewall -> pfBlockerNG** deselect **Enable pfBlockerNG** from the **General Settings** page and click save.
+</WRAP>
+----
+===== Basic Example =====
 Navigate to **Services->DNS Resolver**.
@@ Line 23: / Line 39: @@
 This means all the Unbound commands generated by pfBlockerNG are not referenced when a client in 192.168.10.x queries pfSense, so DNS queries go through unchanged.
-For the 192.168.20.x network, the entries are included and redirected to our sinkhole.
+For the 192.168.20.x network, the entries are included and redirected to the pfBlockerNG sinkhole.
 It is important to note that you can use these entries in any CIDR notation that fall within your network topology.
@@ Line 57: / Line 73: @@
 We have to add them here as adding them as a **Host Override** on the **DNS Resolver** configuration page would enforce them for all clients.
+</WRAP>
+----
+====== Forward all DNS ======
+<code bash>
+server:
+    access-control-view: 192.168.10.0/24 bypass
+    access-control-view: 192.168.20.0/24 dnsbl
+    access-control-view: 192.168.30.0/24 forward
+view:
+    name: "bypass"
+    view-first: yes
+view:
+    name: "dnsbl"
+    view-first: yes
+    include: /var/unbound/pfb_dnsbl.*conf
+view:
+    name: "forward"
+    view-first: yes
+    forward-addr: 1.1.1.1
+    forward-addr: 8.8.8.8
+</code>
+<WRAP info>
+**NOTE:**  The **forward** view forwards requests to a couple of DNS servers on the Internet.
+</WRAP>
+----
+====== Forward DNS over TLS ======
+<code bash>
+server:
+    access-control-view: 192.168.10.0/24 bypass
+    access-control-view: 192.168.20.0/24 dnsbl
+    access-control-view: 192.168.30.0/24 forward
+    access-control-view: 192.168.40.0/24 tls
+view:
+    name: "bypass"
+    view-first: yes
+view:
+    name: "dnsbl"
+    view-first: yes
+    include: /var/unbound/pfb_dnsbl.*conf
+view:
+    name: "forward"
+    view-first: yes
+    forward-addr: 1.1.1.1
+    forward-addr: 8.8.8.8
+view:
+    name: "tls"
+    view-first: yes
+    tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt
+    forward-tls-upstream: yes
+    forward-addr: 1.1.1.1@853#cloudflare-dns.com
+    forward-addr: 1.1.1.1
+</code>
+<WRAP info>
+**NOTE:**  To use **DNS over TLS**, you will need to specify **tls-cert-bundle** option that points to the local system's root certificate authority bundle, allow unbound to forward TLS requests and also specify any number of servers that allow DNS of TLS.
+For each server you will need to specify that the connection port using **@**, and you will also need to indicate which is its domain name with **#**.  Even though it looks like an comment the hashtag name allows for the TLS authentication name to be set for stub-zones and with unbound-control forward control command.  There should not be any spaces between the @ and # markups.
 </WRAP>