Blocking on non-selected interface?



  • How is it that I am seeing DNSBL blocks on an interface that is purposefully not selected to be monitored in the pfBlockerNG config?

    I do not have the "worknet" interface selected in the configuration, see pic:

    0_1533146848369_SS2.png

    As you can see here it is showing blocks on that interface:

    0_1533146824436_ss1.png



  • DNSBL is using unbound, so for devices not to be affected by DNSBL blocking, the devices need to use DNS service not provided by the pfsense with pfblockerNG/DNSBL.



  • Kinda not making sense. I have not selected the interface in the config section, so nothing on that interface should be able to reach the DNSBL VIP. There is also no automatic "pfB_PRI1_v4" rule on that interface so nothing should get rejected, no?



  • Ok it souldn't reach the VIP, but the answer it gets from unbound on the pfsense DNSBL is still the VIP for the blocked domains.

    If you want to allow access to blocked domains, you need to use another DNS Resolver that doesn't block those domains.

    Maybe you can look at : https://forum.netgate.com/topic/129365/bypassing-dnsbl-for-specific-ips



  • Same issue here, we have a number of VLANs and some should be excluded from DNSBL.

    If not to select the interfaces that participate in DNSBL, what exactly is the purpose of the setting for "permit firewall rules"? It would seem the logical place, also from the description that's in there, to rule interfaces in or out...

    -Rob-



  • @rob-beckers The Firewall rules allow the network to reach the DNSBL VIP httpd service.



  • @ronpfs said in Blocking on non-selected interface?:

    @rob-beckers The Firewall rules allow the network to reach the DNSBL VIP httpd service.

    I think what he is saying is why have the ability to select networks if they are all affected anyhow?



  • @ar15usr Well did you look at the pfB_DNSBLIP_v4 auto rule to see if something is wrong?

    Did you traceroute from the devices that are not specified in you Permit Firewall Rules ?



  • A traceroute to yahoo.com results as expected. A traceroute to e.crashlytics.com traces to 10.10.10.1 meaning it is getting blocked.

    There is no auto generated rule on this interface in the firewall rules fyi. I can post a screenshot of the floating rules if you like, let me know.


  • Moderator

    @ar15usr @rob-beckers

    pfBlockerNG has two main components:

    1. IP
    2. DNSBL

    In the DNSBL tab, there is a DNSBL_IP option that will collect any IPs found in the DNSBL (Domain based) feeds and add those to an IP Firewall rule to be blocked. The IP settings allow configuring which Interface IP rules are assigned to.

    Don't mix up IP Blocking and Domain blocking.

    To bypass a DNSBL Block, you either need to whitelist those Domains, or have the LAN devices use an alternative DNS server for DNS resolution. If your LAN and other segments are using pfSense Unbound for DNS resolution, then they will be filtered via DNSBL.

    The DNSBL VIP and Interface selection is only used to define where the DNSBL Web server is located to sinkhole the DNSBL domains. All Lan segments should have access to this web server IP or else there can be timeout in browsing.

    You can manually follow the steps in this post below to create "views" in Unbound that will only filter DNS requests for the selected network segments.

    https://forum.netgate.com/topic/129365/bypassing-dnsbl-for-specific-ips



  • Well I tried that but any of those advanced options in that thread resulted in not being able to resolve anything. Now I cant remember the default line in the advanced options and the DNS Resolver is erroring out when trying to save the options.

    Can you please remind me what the default line that pfBlockerNG adds there?

    is it:

    server: /var/unbound/pfb_dnsbl.*conf
    

    or

    server: 
    include: /var/unbound/pfb_dnsbl.*conf
    

    or something else?



  • @ar15usr This what I have with pfblockerNG-Devel

    server:include: /var/unbound/pfb_dnsbl.*conf
    


  • @ronpfs OK back up now, thanks..


 

© Copyright 2002 - 2018 Rubicon Communications, LLC | Privacy Policy