User Tools

Site Tools


pfsense:pfblockerng:bypass_pfblockerng_for_specific_clients

PFSense - pfBlockerNG - Bypass pfBlockerNG for specific clients

Unfortunately, even if the some interfaces are NOT selected as per this configuration, pfBlockerNG does NOT ignore them and still performs DNSBL checking.

To have pfBlockerNG ignore some interfaces, such as the CLEAR network in this diagram, pfSense needs to use a different DNS server.


Navigate to Services → DNS Resolver.

In the General Settings tab, change:

  • Custom options:
    server:
        private-domain: "plex.direct"
        include: /var/unbound/pfb_dnsbl.*conf

to

  • Custom options:
    server:
        private-domain: "plex.direct"
        access-control-view: 192.168.1.0/24 dnsbl
        access-control-view: 192.168.50.0/24 bypass
        access-control-view: 192.168.70.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf

NOTE: Do not have multiple server options against the access-control-view settings.

Also, do not have the word server: in front of the following statement server:include: /var/unbound/pfb_dnsbl.*conf.

The following line may be needed above the include: /var/unbound/pfb_dnsbl.*conf line:

include: /var/unbound/host_entries.conf

WARNING: If you do an update, disable and re-enable DNSBL the line include: /var/unbound/pfb_dnsbl.*conf will be reset back to the standard entry to start with the word server:, so will become server:include: /var/unbound/pfb_dnsbl.*conf.

This is hard-coded into pfBlockerNG, and until this is fixed, you will need to check each time and remove any leading server: to ensure your expected behavior works as expected.


Another example

Use Cloudflares DNS over TLS hence the forward-zone configuration.

server:
    private-domain: "plex.direct"
    access-control-view: 192.168.1.51/32 bypass
    access-control-view: 192.168.1.61/32 bypass
    access-control-view: 192.168.1.83/32 bypass
    access-control-view: 2601:abcd:abcd:abc0::/64 dnsbl
    access-control-view: 2601:abcd:abcd:abc1::/64 dnsbl
    access-control-view: 2601:abcd:abcd:abc2::/64 dnsbl
    access-control-view: 192.168.1.0/24 dnsbl
    access-control-view: 192.168.2.0/24 dnsbl
    access-control-view: 192.168.3.0/24 dnsbl
    rrset-roundrobin: yes
forward-zone:
    name: "."
    forward-ssl-upstream: yes
    # Cloudflare DNS
    forward-addr: 1.1.1.1@853
    forward-addr: 1.0.0.1@853
    forward-addr: 2606:4700:4700::1111@853
    forward-addr: 2606:4700:4700::1001@853
view:
    name: "bypass"
    view-first: yes
    #include: /var/unbound/host_entries.conf
view:
    name: "dnsbl"
    view-first: yes
    include: /var/unbound/host_entries.conf
    # local-zone: "youtube.com" inform_deny
    # local-zone: "facebook.com" inform_deny
    include: /var/unbound/pfb_dnsbl.*conf

NOTE: A 192.168.0.0/22 mask (CIDR) for the IPv4 subnets did not work, I instead had to define each subnet with /24. Maybe a /16 would have worked?

Same problem with IPv6. (note, the examples mask my real IPv6 prefix), I had to define multiple /64's as a single /62 did not work.

The dnsbl view needed to have include: /var/unbound/host_entries.conf otherwise the host overrides did not resolve. For some reason however that was not required for the bypass view, which seems to operate quite happily without the include: hence it is commented out.

The two commented out local-zone's are an easy way to block social media.


Enforce Google, YouTube, Bing and DuckDuckGo SafeSearch

server:
    access-control-view: 192.168.10.0/24 bypass
    access-control-view: 192.168.20.0/24 dnsbl
view:
    name: "bypass"
    view-first: yes
view:
    name: "dnsbl"
    view-first: yes
    include: /var/unbound/pfb_dnsbl.*conf
    local-data: "www.google.com 60 IN A 216.239.38.120"
    local-data: "www.youtube.com 60 IN A 216.239.38.119"
    local-data: "www.bing.com 60 IN A 204.79.197.220"
    local-data: "duckduckgo.com 60 IN A 107.20.240.232"

NOTE: These entries added in the dnsbl view force all clients in this group (192.168.20.x) to the SafeSearch address for each of the four services included.

These have to be added here, as adding them as a Host Override on the DNS Resolver configuration page, would enforce them for all clients.


Allow websites on a per client basis

  • group A allow websites X and deny websites Y
  • group B allow websites X and allow websites Y
  • group C allow websites X and allow websites Y and allow websites Z

pfBlockerNG can do this using the new tag feature in Unbound.

NOTE: Tagging is only supported in Unbound 1.5.10 on-wards, so you may need to update your pfSense.

Navigatge to Services → DNS Resolver → Custom Options.

# give pfSense a server: tag so it puts directives in correct place
server:                                      

# Define a new tag.
define-tag: "websiteX"
define-tag: "websiteY"
define-tag: "websiteZ"

# Create access control entry.
access-control: 10.1.1.0/24 allow  # group A
access-control: 10.1.2.0/24 allow  # group B
access-control: 10.1.3.0/24 allow  # group C

# Tag the access.
# Allocate IP ranges to the tag.
access-control-tag: 10.1.1.0/24 "websiteX"     
access-control-tag: 10.1.2.0/24 "websiteX"     
access-control-tag: 10.1.3.0/24 "websiteX"     
access-control-tag: 10.1.1.0/24 "websiteY"     
access-control-tag: 10.1.2.0/24 "websiteY"     
access-control-tag: 10.1.3.0/24 "websiteY"     
access-control-tag: 10.1.1.0/24 "websiteZ"     
access-control-tag: 10.1.2.0/24 "websiteZ"     
access-control-tag: 10.1.3.0/24 "websiteZ"     

# Create the local-zone, and allow normal service 
#  which allows non-blocked users access
#  and allow all types like A and AAAA and CNAME.
local-zone: www.websitex.com typetransparent  
local-zone: www.websitey.com typetransparent  
local-zone: www.websitez.com typetransparent  

# Tag the domain.
local-zone-tag: www.websitex.com websiteX       
local-zone-tag: www.websitey.com websiteY
local-zone-tag: www.websitez.com websiteZ       

# Ensure local data served first.
access-control-tag-action: 10.1.1.0/24 "websiteY" redirect  
access-control-tag-action: 10.1.2.0/24 "websiteZ" redirect  

# Send users to your polite internal block page.
access-control-tag-data: 10.1.1.0/24 "websiteY" "A 10.1.1.1"
access-control-tag-data: 10.1.2.0/24 "websiteZ" "A 10.1.1.1"

References

pfsense/pfblockerng/bypass_pfblockerng_for_specific_clients.txt · Last modified: 2021/01/28 09:23 by peter

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki