Bypassing DNSBL for specific IPs



  • @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
    


  • 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.



  • @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.



  • @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.



  • @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")

    1. I have unselected DMZ interface from Unbound's Network Interfaces.
    2. There are no NAT or port forward applied to DMZ (as far as I know).
    3. 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.
    4. 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....)



  • @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 . . . .



  • @horse2370 : Yeah you are right.

    From pfsense:

    Leave blank to use the system default DNS servers: **this interface's IP** if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the System / General Setup page.
    

    Unbound being enabled, the interface's IP is forwarded as DNS server on clients, this is what I see from ipconfig on my work laptop running windows 10.

    I will google how to keep unbound active for other interfaces and have the DNS servers forwarded to DMZ. I tried restarting Unbound but didnt help.

    EDIT: Yeah... DNS Forward was disabled in Unbound's options..... I may slap myself behind the head. I now understand that I can revert Unbound's Advanced options to simply "server:include: /var/unbound/pfb_dnsbl.conf" and delete everything else since I no longer need views?



  • @pftdm007

    I think the help text means unbound is enabled on pfSense, not specifically the interface. i.e. globally.

    I would just add the DNS servers to the DHCP server configuration for the DMZ. Keep it really simple. This is the same kind of recommendation used in Enterprise networks for Wireless Guest. That way, guest bypass corporate DNS and just get public.

    You LAN clients uses unbound (with forwarding to Google) and DNSBL filters, DMZ clients use Google directly, etc.



  • @horse2370
    I added the DNS servers (1.1.1.1 + 1.0.0.1) to DMZ's and the clients are now seeing the DNS servers with "ipconfig".

    Seems its all working fine for now! There is still a little issue with random skype call drops when connected to DMZ, I will investigate then open a separate thread if need be.

    Thanks to all for the help and patience, especially you @horse2370 !



  • @horse2370 said in Bypassing DNSBL for specific IPs:

    the same kind of recommendation used in Enterprise networks for Wireless Guest. That way, guest bypass corporate DNS and just get public.

    Right !! 👍

    @horse2370 said in Bypassing DNSBL for specific IPs:

    You LAN clients uses unbound (with forwarding to Google)

    Euh .... Corporate clients networks forwarding to Google ??
    Wrong ☺
    At least in Europe, that's not a recommendation thing, one could get fired for that. Maybe in the States other rules or reasons exist, I can't tell.
    For me, "8.8.8.8" is at maximum a soHO thing.
    (I really guess because our society fabricated a lot of people that are trained to "have to enter a DNS" because our ISP's trained us to do so in the past. They had their reasons, but these do not exist any more).

    But if someone can tell me ones and for all what the benefits are, I'll adopt "8.8.8.8" myself, promised.
    Btw : don't get me wrong : I'm using gmail (just perfect for automated notification systems).
    I do like their search engine a lot - it works for me ™
    I'm not against Google as a company (how could I).



  • @pftdm007

    Great! Your Welcome

    @Gertjan

    Thanks for clarifying in case others also thought I recommended Enterprise customers forward to Google from their internal DNS. What I thought I wrote was ONLY referring to Guest network recommendation.
    My last sentence in that post was specific to pftdm007's environment, although it should have started with "Your" and not "You" :-)
    To clarify - The general recommendation is to keep guest traffic isolated from internal resources, i.e use the internal DHCP servers on the network infrastructure, such as the WLAN controllers as typically that is where the capture portal is anyway, and have them use an ISP or Public DNS (i.e. non-enterprise), instead of letting the guest traffic roam around the datacenter/datacentre servers before being routed (you can pronounce "routed" correctly :-) ) out the Internet gateway.
    For the Enterprise's own DNS, it should follow standard best practices, which as you correctly point out would not typically include forwarding all your DNS traffic to Google's Public server to data mine.
    As always the answer is never quite that simple and it always depends. Some smaller companies may choose to utilize a Public/Cloud DNS service as part of their security posture, but that would be an authoritative name service. Hence, one of the reasons Cisco acquired openDNS, or you could even use Google Cloud DNS among many others.

    Like you, I use Google, however when it comes to privacy. . . . . . not so much. Yes I'm in the states, but originally from the UK and deal with customers World Wide and am exposed to all kinds of regulations. Most good, some just plain political and a PIA. The amount of time spent on training for compliance is getting beyond a joke. Soon I won't have time to do actual work that might contravene a regulation.

    My home DNS used to resolve from root severs and I have a managed provider for my personal domains for simplicity and resiliance. I certainly avoid forwarding to my ISP's DNS and even using root servers when my ISP started hijacking DNS on UDP 53.
    Quick Google for a supporting article provides some details Comcast hijacking DNS
    I switched to encrypted DNS on community supported DNS servers, until Cloudfare rolled out their free public service for people like me.

    I could see one benefit of using Google for your DNS, they would mine those requests and know what you needed to buy before you did 😏

    As with anything, there are exceptions to every rule, your mileage may vary and it will always depend!

    Stay safe



  • I just realized... DNSBL can be bypassed by passing different DNS servers to my DMZ clients (so they do not go thru Unbound), but what about pfBlockerNG?

    WAN is selected in Inbound, and LAN is selected for outbound, but not DMZ (so not to have pfblocker block traffic on DMZ).

    In pfsense's FW logs, I see entries showing blocked traffic on WAN that is going to DMZ. This is my understanding: DMZ client sends traffic to the internet, nothing is blocked (pfblocker & DNSBL are not running on DMZ). Request gets sent to the internet, the response comes back, it is blocked by pfblocker on WAN.

    I had Snort running on LAN and WAN, but not on DMZ. It kept blocking incoming traffic on WAN that was coming back to DMZ. User @bmeeks kindly explained that it was unnecessary to have Snort run on WAN. The logic is that all unsolicited inbound traffic is blocked by FW rules so only stateful responses are allowed, and since the initial traffic had gone thru Snort on LAN, it is considered "safe". Sorry for the gross over-simplification......

    Is it the same logic for pfblockerNG??? How do you guys run these packages? I'm slowly realizing that I have made several mistakes in setting up my pfsense box....



  • Correct, if any client can bypass unbound on the pfSense, it will not benefit from the pfBlockNG functionality. Hence on my pfSense deployment at home, I have a FW rule on the LAN, DMZ and VPN interfaces that only allow UDP 53 (DNS) to pass if the destination is the local interface address. I have another rule that denies and logs any other requests going to other DNS addresses which I can see in the logs and my splunk setup. (Allow/Permit rule is before the deny and log rule) This shows Amazon and Google assistants trying their hardest along with my Roku's, same is true for them trying to track and report usage statistics.

    Regarding you other question about pfBlockerNG, I'm going to over simplify as that is the other function of pfBlockerNG. (i.e. it does DNS filtering and the other function is IP address filtering) If you have setup the feeds, you should see "auto rule" in the Firewall Rules admin page.

    Again on my setup, I am blocking Banned Hosts, Emerging threat hosts inbound on the WAN and outbound on all other interfaces. In addition I only allow inbound connection from specific countries that have family or other services that need access to the DMZ to pass. (i.e. Mail Relay and Plex) If I travel outside these normal countries I do have to modify this rule so I can still VPN and access my DMZ services. This is all done via the GeoIP admin pages.

    Your other question about inbound traffic being blocked to the DMZ, I will again over simplify, but the basic premise of the FW functionality is, any session that is initiated from a "trusted" interface (LAN, DMZ) will be allowed and the inbound traffic for that session will also be allowed back through the WAN interface. For TCP, this is tracked my SYN's and FIN's for when to allow that port and when to close it. UDP relies on the same ports being used (src/dst flipped) for the return traffic and typically timers. Therefore if you are seeing blocked traffic ( and assuming you have a fairly out of the box config) those are typically from session you have not initiated or unsolicited There are many exception to this oversimplification, mainly with Video and voice protocols.

    In summary, my setup uses pfBlockerNG's DNS functionality to block ads, tracking, malware and phishing sites. My logs show the PiHole feed block 95% of them. Side effect is faster page loading and a significant drop in downloaded traffic which is good as I have a 1TB cap per month.
    pfBlockerNG's IP functionality keeps bad hosts and restricts countries that should not be connecting, out of my DMZ. And stops inside hosts from accidentally connecting to bad hosts. The GeoIP/Country filter does not apply outbound obviously. The Firehol feed does most of the heavy lifting based on the reports and splunk dashboards.

    For me, this strikes a balance between family usability of the Internet and keeping it reasonably safe and secure.

    Side note, I do have Snort installed, however it is is IDS (monitor) mode with a couple of http SID's suppressed as they caused many false positives, end result, I very few alerts and check for unusual alerts every few days.

    Snort is enabled on my WAN, along with a number of FW rules that log, this is only so I can see what kind of attacks are occurring for research purposes and track the percentage of encrypted IPv4 and IPv6 traffic. This is captured in dashboards that I have configured in splunk and I use for work.
    Encrypted traffic continues to rise as does the split between IPv4 and IPv6. The later being significantly offset to IPv4 when the family is streaming more as the Roku's are v4 only.

    Hope that helps . . . . .



  • I still wonder if I am chasing a ghost or something real... Here's an actual real life example:

    My work laptop is connected to DMZ. Connection straight to the outside, no DNSBL running on DMZ, no pfblocker running on DMZ, no Snort, nothing. Straight out with the exception of a few FW rules blocking anything nasty (connecting to pfsense, communicating with other subnets, etc).

    This laptop is totally dysfunctional. Intermittently, web pages dont load, stuff breaks and crashes, proxy app keeps re-creating new connections to its mother ship, etc. My employer's IT support are blaming my "home network". This laptop runs a proxy service that connects to "gateway.zscalertwo.com" on port 18000.

    In pfsense's FW logs, I see hundreds and hundreds of entries showing blocked traffic on DMZ. All of these have "Default deny rule IPv4" as description. That doesnt say much....
    111.png

    Since the FW rules on DMZ are very basic and pretty much allow anything, I started searching for an explanation somewhere else... I found in pfBlockerNG > Reports > IP Block Stats:

    222.png

    Clicking on the filter icon:

    333.png

    So I'm going back to my original thought. To me pfblockerNG interferes with traffic on DMZ. How can I disable this without whitelisting stuff???



  • Nope, your not chasing ghosts, but if you were, you know who to call!
    That looks like you have pfBlockerNG's IP block rules enabled on the DMZ outbound interface.

    The clue is the list name is "pfb_malicious_malware_v4"

    You have a number of things you can do to either remove it completely, or fine tune it to remove this functionality on the DMZ interface only.

    To prove it using the sledgehammer approach, disable pfBlockerNG in the Global Tab, this will turn of DNSBL and the IP Block functions on ALL interfaces. Your work laptop should then function normally.

    To remove this from just the DMZ, first check on the Firewall > Rules > DMZ tab and you should see something like this: -

    Screen Shot 2020-04-26 at 17.43.33.png

    The name will be different, but it will have a "pfb" prefix and a "v4" suffix and the description will indicate it is an auto rule.
    Assuming there is a rule on your DMZ, you can remove it using the Firewall > pfBlockerNG > IP page under "Outbound Firewall Rules. Deselect the DMZ. My guess is you have LAN and DMZ selected currently.

    If you want to keep the IP Blocks enabled in the DMZ to protect your other devices not using the zscaler service, which protects your work laptop from malicious web sites. You will need to figure out which list has the zscaler ip address tagged as a malicious malware site. That will be in the "Feeds" tab within pfBlockerNG's pages.
    You can check that the 185.46.212.41 is in the pfb_malicious_malware_v4 list, by using the Diagnostic > Tables option and selecting the list name from the drop down and scrolling through the table.

    Some of the lists in the feeds are somewhat aggressive, like one I enabled stopped my son from doing his school work on google docs. He was quite happy about it, but I soon solved that problem and had to get back to his school work.

    Hopefully this points you in the right direction. I work in the industry and everything works just fine, until you enable security, the more you enable, the more it becomes a house of cards. Its a balance between safety and security and it just not being useful anymore. Finding the balance is key. Everyone is different.



  • Hey @horse2370 , thanks for the reply!

    Okay I took some more screenshots of my setup. As they say "The plot thickens".

    Before all of that, I had taken the precaution to make sure pfblocker was disabled on DMZ, here's a screenshot of the IP configuration page. As you can see, pfblocker is selected only on LAN (my main home network). DMZ is not selected :
    1111.png

    Also under Rules > DMZ I do not see any pfblocker rules (as expected!):
    2222.png

    But still, this morning, the FW logs are filled with blocked connections on DMZ. Today, however, there's all kind of destination IP's in there (WAN, Amazon servers, Zscaler, etc...):

    3333.png

    All (literally ALL) of these blocked connections have the following reason:

    The rule that triggered this action is:
    @9(1000000103) block drop in log inet all label "Default deny rule IPv4"
    

    Until I sort this mess out, I will have to either commute to my office or physically bypass pfsense completely and connect the laptop directly to the cable modem.

    Any idea of what's going on? I know these "TCP:RA" or "TCP:PA" could be asymetrical packets.... I am 99.9% sure I never had this before. Could my ISP be doing some sort of f*ckery with my connection?



  • @pftdm007 said in Bypassing DNSBL for specific IPs:

    The rule that triggered this action is:
    @9(1000000103) block drop in log inet all label "Default deny rule IPv4"

    Most easy solution : stop login the hits on the default block rules. (see Log > Settings )

    Your 192.168.2.206 is a device that lives on DMZ, a VLAN.
    Take it out of the VLAN to bypass "smart switch issues".
    On the device, find why these "TCP:RA" or "TCP:PA" are send .... Is it a Wifi connected device ?

    Probably not a pfBlockerNG-devel issue. Disable pfBlockerNG-devel and these hits continue ?



  • @Gertjan said in Bypassing DNSBL for specific IPs:

    Your 192.168.2.206 is a device that lives on DMZ, a VLAN.

    Correct. So is my work cell phone. Same issue with my cell phone.

    @Gertjan said in Bypassing DNSBL for specific IPs:

    Take it out of the VLAN to bypass "smart switch issues".

    OK will try to connect the laptop to a non-VLAN subnet, but in the meantime, all of my other computers/servers/networked printers, are all on LAN which is also a VLAN, and I have absolutely zero issues with any of them. Side note: everything is a lot more severe on LAN (more pfB/DNSBL lists, Snort, etc...)

    @Gertjan said in Bypassing DNSBL for specific IPs:

    On the device, find why these "TCP:RA" or "TCP:PA" are send .... Is it a Wifi connected device ?

    My employer's IT are investigating on the device to see if everything is properly setup & running.... In the meantime, yes the laptop & cell are wifi connected to DMZ, but I already tried connecting the laptop via wired connection, same issues. That kinda eliminates possibilities of issues with my WIfi access point.

    @Gertjan said in Bypassing DNSBL for specific IPs:

    Disable pfBlockerNG-devel and these hits continue ?

    When they release the laptop, I will reconnect to DMZ, and try. I am pretty sure I already tried, but I've done so many things in the last few days I am getting a bit confused so I will retry to make sure.



  • guys what is wrong in my custom config since all LAN subnet 192.168.1.0/24 is being filtered by DNSBL ? I want some computers (192.168.0.1 and 192.168.0.2) to be excluded from DNSBL filtering.

    server:
    access-control-view: 192.168.0.1/32 bypass
    access-control-view: 192.168.0.2/32 bypass
    access-control-view: 192.168.0.0/24 dnsbl
    view:
    name: "bypass"
    view-first: yes
    view:
    name: "dnsbl"
    view-first: yes
    server: include: /var/unbound/pfb_dnsbl.*conf



  • These are 'clauses' in the (unbound) config file :

    server:
    ....
    view:
    ...
    

    They are recognised by the terminating ':'.
    "view:" clause can exists multiple times.
    "server:" clause can't (there is only one server)

    Or, you have two of them.

    This one is thrown in by the pfBlockerNG-devel package :

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

    That is, you edited it. pfBlockerNG-devel package added this :

    #  Unbound custom options
    server:include: /var/unbound/pfb_dnsbl.*conf
    

    This is the same thing :

    # Unbound custom options
    server: 
       include: /var/unbound/pfb_dnsbl.*conf
    

    So, I guess this would work for you :

    server:
       include: /var/unbound/pfb_dnsbl.*conf
      access-control-view: 192.168.0.1/32 bypass
      access-control-view: 192.168.0.2/32 bypass
      access-control-view: 192.168.0.0/24 dnsbl
    view:
      name: "bypass"
      view-first: yes
    view:
      name: "dnsbl"
      view-first: yes
    

    Btw : Use this when you start to add unbound specific manual settings. It's part of the RTFM concept ;)

    Be careful : if

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

    can't be found by pfBlockerNG-devel when it start, it will automatically add such a clause again into the unbound config file.
    Remember, pfBlockerNG-devel parses as a program, not as a human ^^
    Adding a seconds "server:" clause probably breaks the unbound config ....



  • @Gertjan thanks. removing server: clause solved problem. I hope pfBlockerNG-deve won't add it again



  • Hi, been reading through this post but confused. I want to allow my IP 192.168.1.16 to bypass the blocker, is this correct?

    Go to Services/DNS resolver/General Settings then in Custom options write:

    server:include: /var/unbound/pfb_dnsbl.*conf
    access-control-view: 192.168.1.16/24 bypass
    access-control-view: 192.168.1.16/24 dnsbl
    
    view:
      name: "bypass"
      view-first: yes
    view:
      name: "dnsbl"
      view-first: yes
    


  • server:
    access-control-view: 192.168.1.16/32 bypass
    access-control-view: 192.168.1.0/24 dnsbl
    
    view:
      name: "bypass"
      view-first: yes
    view:
      name: "dnsbl"
      view-first: yes
      include: /var/unbound/pfb_dnsbl.*conf
    

    The changes are: -

    access-control-view: 192.168.1.16/32 bypass
    

    Matches the host you want to bypass with a /32 to make it ONLY match the single address.

    access-control-view: 192.168.1.0/24 dnsbl
    

    Matches the rest of the subnet, assuming a 255.255.255.0 mask.

    Moved the include: to the "dnsbl" view



  • Thanks very much! Is it possible to something more fine grained. Like allow 192.168.1.16 to www.blockedwebsite.com?



  • I have tried the following file and it appears to work, by adding a local-data entry in the view, and not allowing it to fall back to the global local-data entries . It has the benefit of keeping the pfblockerng-generated entry

    # Allow these hosts to bypass pfblockerng
    server:access-control-view: 192.168.0.2/32 bypass
    
    view:
      name: bypass
      view-first: no
      local-data: "dummy.entry 60 IN A 10.10.10.1"
    
    server:include: /var/unbound/pfb_dnsbl.*conf
    


  • Hi All,

    I see this thread has been ongoing for a few years.  How is that?  Is there a systematic way to make suggestions so this gets added to pfBlockerNG-Devel?  It seems like a reasonable request.  If we can't get this added to the GUI is there something else the customer can do?  i.e. whitelist the host for 15-60 minutes so they can get the info they need without getting blocked?

    having end users manually point to a different DNS server just makes it a pain in the ass.  Asking end users to run Opera in VPN mode is also extra steps and eventually I would want to block that as well except for a few users/ip addresses.  Having a separate machine or VM on a different network is something our users would call us out on.

    Do all the edits to these text files migrate during version upgrades or do we have to remember to re-do all the custom stuff we tinker with?

    Thanks,
    Joe



  • @Gertjan I had this working 4 months back:

    server:
        access-control-view: 192.168.0.20/32 bypass
        access-control-view: 192.168.0.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
        include: /var/unbound/pfb_dnsbl.*conf
    

    but later HDD of my custom firewall crashed, and Covid-19 lockdown began.

    Meanwhile, I took firewall home, replaced HDD, upgraded pfSense to 2.4.5, upgraded pfblockerng-devel to 2.2.5_33. Now my bypass doesnt work. Everytime Firewall restarts or Enable/Disable pfblockerng, it changes unbound custom option to:

    server:
        access-control-view: 192.168.0.20/32 bypass
        access-control-view: 192.168.0.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
    server:include: /var/unbound/pfb_dnsbl.*conf
    

    i.e. it adds another server: clause in the last line. You mentioned that there can't be multiple server: clause.
    bypass still doesnt work. Can you please help?



  • Try this :

    server:
        access-control-view: 192.168.0.20/32 bypass
        access-control-view: 192.168.0.0/24 dnsbl
        include: /var/unbound/pfb_dnsbl.*conf
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
    


  • Thanks @Gertjan for responding quickly.

    I tried what you suggested, but bypass still not working.

    Additionally, when i tried to enable/disable pfBlockerNG(with above custom option), it moved the include: to the last line, with additional server: clause.

    server:
        access-control-view: 192.168.0.16/30 bypass
        access-control-view: 192.168.0.26/32 bypass
        access-control-view: 192.168.0.0/24 dnsbl
    view:
        name: "bypass"
        view-first: yes
    view:
        name: "dnsbl"
        view-first: yes
    server:include: /var/unbound/pfb_dnsbl.*conf
    

    Anymore ideas worth trying?



  • @Gertjan said in Bypassing DNSBL for specific IPs:

    Most easy solution : stop login the hits on the default block rules. (see Log > Settings )

    Sorry Gertjan, I am not following your suggestion here. Do you mean "the Settings tab under Status > System Logs"



  • @SmokinMoJoe said in Bypassing DNSBL for specific IPs:

    Do you mean "the Settings tab under Status > System Logs"

    Yep, this one:

    439ab09d-da5f-4c63-a37d-4efcc492c88f-image.png

    @HiteshJain said in Bypassing DNSBL for specific IPs:

    when i tried to enable/disable pfBlockerNG

    pfBlockerNG is a program.

    It's adds "server:include: /var/unbound/pfb_dnsbl.*conf" without taken in account if you have anything else already in there.

    Normally, this isn't a big issue, because, normally, you do not need to enable and disable pfBlockerNG all the time.
    And if you do, you have to visit the Resolver config page afterwards to "correct" the custom config options somewhat - if you have other, your own config settings entered.
    The syntax has to be correct for unbound, who parses the config file.

    Btw : My proposition about how to format is : how I should do it.
    There is another forum thread that details how to do so already, use that one to compare it with yours.



  • @HiteshJain I have evolved the config I posted last month. It still allows pfblockerng to regenerate the configuration correctly, without corrupting it, and adds in a few addtional files which were needed.

    # Allow these hosts to bypass pfblockerng
    server:access-control-view: 192.168.0.2/32 bypass
    
    # A view to bypass pfblockerng
    view:
        name: bypass
        view-first: no
        # This is needed to prevent falling back to the
        # global 'local-data' settings
        local-data: "dummy.entry 60 IN A 10.10.10.1"
        # Static host entries
        include: /var/unbound/host_entries.conf
        # dhcp lease entries
        include: /var/unbound/dhcpleases_entries.conf
        # Domain overrides
        include: /var/unbound/domainoverrides.conf
    
    server:include: /var/unbound/pfb_dnsbl.*conf
    


  • @Mi88Shz Even this config is unable to bypass for me.

    Moreover, your config contains 2 server: clause which as per @Gertjan cant be multiple.

    Are you able to bypass for specific IPs?



  • @HiteshJain said in Bypassing DNSBL for specific IPs:

    2 server: clause which as per @Gertjan cant be multiple.

    I actually said this :

    @Gertjan said in Bypassing DNSBL for specific IPs:

    "server:" clause can't (there is only one server)

    I guess I dive back into the manual ....

    But before that : I've seen thousands of these type of files : you've seen one, you've seen them all.

    See :

    505b8be2-1edf-4143-8dc8-85150a5e51df-image.png

    server clause - not server clauses.

    Maybe several server: "Attribute keywords" can exist .... you tell me ;)

    In real world examples I see only one ...



  • @Gertjan I didnt mean to offend you by quoting you. I apologize :). Probably, I misunderstood your statement because I dont have any idea on how Unbound works or even configured.
    I got to read about Unbound only because google results directed me to pages where people more experienced than me mentioned about using custom options of Unbound to bypass few IPs , and I wanted exactly same in my pfSense.

    @Gertjan The way you explained in one of the earlier replies of yours, gave an impression that you know a lot about Unbound(& related stuff) and that impression is still maintained. I'd like to Thank you that you take time out to respond to newbie like me.

    I tried to look at Unbound manual, but I gave up just after scrolling the page down to bottom of earth.

    BTW, I am still searching for the right configuration thread from which I could compare my config. Current thread is most appropriate thread i could find so far.
    Do you mind sharing the link of thread you mentioned earlier?



  • @HiteshJain said in Bypassing DNSBL for specific IPs:

    I didnt mean

    Don't worry, non taken.
    But I probably fckd up anyway. Have a look at the first messages in this thread :
    The "include: /var/unbound/pfb_dnsbl.*conf" line should be part of the view: part that handles the "dnsbl".



  • @Gertjan Unfortunately, bypass is still not working. ☹

    I have also tried to reinstall pfBlockerNG twice, once with 'Keep Settings' checked, another without it.
    My pfSense doesnt seems to like bypassing IP.
    ☹


Log in to reply