Bypassing DNSBL for specific IPs

Gertjan

@pftdm007 said in Bypassing DNSBL for specific IPs:

and how to prevent pfblockerNG from adding the redundant "server:" statement in front of the line....

Well ...
Have a keyboard ?
Here it is :

/usr/local/pkg/pfblockerng/pfblockerng.inc line 1289

	$unbound_include = "server:include: {$pfb['dnsbl_file']}.*conf";

Take note : this line is still added at the end of the unbound config file. No analyses is done for Custom options already present.
When pfBlockerng installs, or when you re-enable DNSBL mode, that line is added.

horse2370

@Gertjan
Nice!

Keyboards still rule!, As "Alexa, please make change to pfSense /usr/local . . . . @ line 1289" just isn't going to hack it anytime soon :-)

Gertjan

I really wouldn't ask Alexa to do this ......
Anyway, I tried it myself.

Disabled :

and forced a Update > Reload >All.

My Unbound > Custom options box is now empty.
I added a single (needed !) line :

I edited the file mentioned above.
And activated DNSBL in pfBlokcerNG again :

The result :

	$unbound_include = "# With some comments\n# while I was here.\n include: {$pfb['dnsbl_file']}.*conf";

pftdm007

@horse2370 : pfBlockerNG-devel v2.2.5_30 is installed on my system. Seems to be the latest one. Also the thread you referred me to, seems to be a bug in Unbound or its implementation in pfsense? Still unfixed? The thread ends up dead with no answer.

If "upgrading, installing, disabling / enabling etc." will always put the "server:" statement back in unbound's custom options, then to me, pfBlockerNG's devs never intended their package to work with Unbound views. This is highly confirmed by @Gertjan's workaround to manually edit "/usr/local/pkg/pfblockerng/pfblockerng.inc"...

IMO, and this is only personal opinion, we should never have to fiddle with internal files like this way, even if it works. Especially on production systems. Will this file be overwritten once pfblockerNG is updated?

At least now I start to have a better picture on how these components interact with each others....

pftdm007

@horse2370

Just saw the last line of your post... No, I do not use IPV6 at all. Pretty much everything else is stock, with the exception of pfblockerNG and Snort. I also use VLAN's. Could you specify which setting you need more specifically? I will be glad to provide!

EDIT: some Unbound settings
Port 53
Enable SSL/TLS: Unchecked
SSL/TLS Cert: stock setting
Network ifaces: VLANs (see my initial post on this thread for details)
Outgoing ifaces: WAN
System Domain Local Zone Type: Transparent
DNSSEC: Checked
Python Module: Unchecked
DNS query FW: Unchecked
DHCP Registrations: Checked
Static DHCP: Checked
OpenVPN : Unchecked
Custom Options: (see my initial post on this thread for details)

Gertjan

@pftdm007 said in Bypassing DNSBL for specific IPs:

Will this file be overwritten once pfblockerNG is updated?

It's part of the package - so a re install or upgrade will undo changes.
Or, before editing, make a copy of it.

@pftdm007 said in Bypassing DNSBL for specific IPs:

pfBlockerNG's devs never intended their package to work with Unbound views.

It's just a way to have unbound to include a file with IP's - the scope is just 'server' (unbound dns) wide.

Btw : in my case, this file is empty, I'm not using DNSBL part of pfBlockerNG-devel - so it'a a no-op for me.
I could even wipe this line in the custom options.
( but shouldn't be surprised the DNDBL functionality wouldn't work anymore )

denx

Does the order in which you put the networks in the custom configs make any difference? Like would

access-control-view: 192.168.2.0/24 bypass
access-control-view: 192.168.1.0/24 dnsbl

be any different than

access-control-view: 192.168.1.0/24 dnsbl
access-control-view: 192.168.2.0/24 bypass

?

My custom configs were working fine but something broke so I'm trying to nail down what it might be.

horse2370

@pftdm007 Have you managed to save the config with the advanced options? Like remove everything and save, does that work? Just add the server: Include . . . line?
Then the views without the leading spaces?

From the configuration provided, it looks very similar to mine, only real difference is I have forwarding enabled as I used SSL/TLS to my Internet DNS servers, but I had views working long before that and even before that config had to also be in custom options.

@denx I'm no expert, but based on my networking background, I don't why that would make any difference.
Best practice is general is always to have more specific matches first, but in your case they are both /24's

denx

@horse2370 Thanks! After messing around a bit, I discovered that the order in which you put the networks/hosts makes no difference. The culprit for my problems was, indeed, the "server" prefix in the last line. Deleting it solved the issue.

horse2370

@denx Great - as for the server: unless you want to make the modification posted by Gertjan, keep checking if make any changes to pfBlocker as it will come back.
I have a note on in my "Change Log Documents" to verify so it doesn't bite me.

To help out pfdm007, do you have leading spaces in your Custom Options?

TIA

pftdm007

Finally got to do some testing....

@horse2370 : Yes if I remove evething in Unbound's custom options box, it saves. I also managed to find a workaround:

Shutdown DNSBL/pfblockerNG, it will remove its line in Unbound's options
Keep everything else in Unbound's options
Remove the leading spaces
Save (no problems!)
Start DNSBL, it puts back its line in Unbound's options
Remove the "server:"
Save the options

Now I need to check if the bypassing works, but at least I got past the saving issues....

pftdm007

After all, it seems it is working now. In retrospect, I think there are still some bugs and things to iron out, and DNSBL's devs should definitely support unbound views, but at least it all works at this moment. Big thanks to you guys!

mdngi

I'm sure this is obvious and likely just not the way you want to go, but another solution is to create a separate interface (vlan) for certain hosts and exclude this interface from using unbound (and pfBlockerNG/DNSBL) altogether. Then just allow hosts on this interface/vlan to access "respectable" external DNS servers. I did this for a gaming PC so that I didn't have to compromise my tight pfBlockerNG/DNSBL config for the sake of a single computer that wanted to talk to the world.

kezzla

While this solution may work for some, I would prefer to still have some blocking on the additional vlan. I just really wanted the ability to have policy based blocking like the Sensei plugin offers for Opnsense. I'm currently trying it out with the $9.99 home plan, and so far it has been working as expected. It was so easy to set up as well, it just sucks having to pay 10/month :P lol Really would prefer to go back to pfsense. My goal was to find basic ad blocking on some (adult) pc's, and much stricter blocking for my kids pc's and guest devices.

I could have used other options, like pi-hole or opendns for the kids, but I want it to all go through my router and not depend on other services. Thanks for all the input so far!

pftdm007

@mdngi said in Bypassing DNSBL for specific IPs:

I'm sure this is obvious and likely just not the way you want to go, but another solution is to create a separate interface (vlan) for certain hosts and exclude this interface from using unbound (and pfBlockerNG/DNSBL) altogether

That's exactly what I wanted to do since day 1. Read my original post on this thread:

Basically I want all traffic on a specific VLAN (named DMZ with 192.168.2.0/24) totally bypass pfblocker & DNSBL in both directions (incoming and outgoing)...

Does it mean that there is a simpler/more permanent way of doing this? You need to detail how because AFAIK, all interfaces have their traffic go through the same DNS resolver (Unbound) and the distinction between filtered or not is done at the resolver level via the line :

include: /var/unbound/pfb_dnsbl.*conf

mdngi

It's basically 4 things.

1). Configure unbound to not listen / respond to queries from clients on the excluded interface ("Network Interface" on the general tab of the DNS Resolver settings)

2). Don't configure any NAT / Port Forwarding for DNS on that interface (i.e. don't force DNS through pfSense like you probably would for the other interfaces)

3). Configure your DHCP settings for that interface with the DNS server(s) you want to use on the hosts for this zone (eg. Google, OpenDNS, etc) OR set the DNS server manually on the host.

4). Create the necessary FW rules for that interface to allow DNS out to the open internet / to the DNS servers you specified in #3.

horse2370

@pftdm007

If you want to bypass all pfBlocker's functionality on your DMZ subnet and you are not whitelisting. i.e. you allow all traffic from your DMZ outbound (or at least are not blocking DNS on UDP 53), then you can keep it really simple.

For DHCP hosts, just add a public DNS server(s) in the DHCP server settings for the DMZ.
For static IP Hosts, (or DHCP if you want to do it on each host) just configure a DNS server manually on each host. It doesn't matter if unbound is listening on the DMZ interface or not, if nothing gets sent to the interface ip address on UDP 53, it won't reply.

Also, by still using my local unbound to resolve, I still get local host resolution, as not all my "internal" hostnames have records in my domains public Nameservers (DNS), hence my "views" configuration has

include: /var/unbound/host_entries.conf

for both dnsbl and bypass views. My certificates use hostnames as IP addresses can change, mainly my IPv6 as the prefix is allocated by Comcast dynamically. IPv4 if I decide to move stuff around :-)

That and for my own reasons (Keeps Comcast from tracking and hijacking my DNS) I use Cloudfare's DNS via DNS_over_HTTPS, which means unbound forwards all my DNS requests encrypted to Cloudfare. If you use one of there other two DNS services (1.1.1.2 or 1.1.1.3) you can also have them filter DNS requests for you based on their own reputation models.

mdngi

@horse2370

Thanks for all the good info. Agreed that unbound wont reply if nothing is sent. I went down this road because I had initially NAT'd all DNS so it had to go through unbound regardless of the intended destination. I had to reverse a few things. In a nutshell, step #1 from my list is completely unnecessary (agreed). Step #2 is unnecessary if you hadn't created a port forward in the first place.

Also agreed that the downside to not going through unbound at all is the lack of local host resolution. But, on this machine it's not a big problem.

Currently using OpenDNS (or a completely different DNS for hosts going through VPN), but will play around with CloudFlare over TLS.

pftdm007

@mdngi

I have followed your recommended steps, but for some reasons, clients on my DMZ are not resolving (example Chrome says "DNS_PROBE_FINISHED_BAD_CONFIG")

I have unselected DMZ interface from Unbound's Network Interfaces.
There are no NAT or port forward applied to DMZ (as far as I know).
The DNS servers fields under DHCP server settings for DMZ are all empty. AFAIK, when empty it will use the general DNS servers under System > General Setup which are 1.1.1.1 & 1.0.0.1 for me.
There are 3 firewall rules on DMZ

-> Block any traffic from DMZ subnet to LAN subnet
-> Block any traffic from DMZ subnet to "This firewall"
-> Allow any traffic from DMZ to * . *

Since rules are processed top-down, I'd expect the DNS requests on DMZ clients to match the last rule??? I must be missing something! If I suppress (deactivate) the second rule (block to this FW), same problem occurs.

EDIT: In order to keep the setup as straight FW as possible, and since I do not need local host resolution, I have no issue completely bypassing Unbound and using pfsense's DNS servers directly. I just want to avoid having to configure each client manually (most of the clients on DMZ are mobile devices that I will see only once....)

horse2370

@pftdm007

Have you tried specifying the public DNS servers in the DMZ DHCP pool config. i.e. don't leave that field blank?
I suspect that because unbound is enabled on pfSense, the DMZ DHCP server is still providing the DMZ Interface address for DNS, I don't think its aware you are not actually listening on that interface. Not able to double check at the moment.

Check one of your DMZ hosts and see what DNS IP address they are using. Is it the same as the gateway?

Just a thought . . . .