Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    DNSBL Listner IP casing serious Firewall issues

    Scheduled Pinned Locked Moved pfBlockerNG
    7 Posts 2 Posters 938 Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • keyserK
      keyser Rebel Alliance
      last edited by keyser

      Hi @BBcan177

      Thank you for creating a REALLY excellent and by far the most valuable add-on package for PFsense.

      I have been having some trouble with my Firewall rules ever since enabling DNSBL because the way you create your listener IP address for the "addblocked Webservice" is very much against good network design practises. It's only possible to create your listener as a second L3 - out of subnet - IP address interface on an already existing L2/L3 combined interface. Having 2 different IP subnet interfaces on the same L2 interface is VERY poor network design.

      What causes me to open this thread, is that this second L3 address created issues with how firewall rules are handled in PFsense. Please see this thread on how your L3 interface disables the correct interpretation of "Invert Match" firewall rules:
      major-security-flaw-invert-match-rules-not-working-as-intended-with-dnsbl-enabled

      I would like to propose that you add the option to have the webservice listening on the Loopback interface where it really should exist instead. That way I (or you automatically) can create a NAT rule on each interface that allows access to the service on the loopback adapter - as proper network design would dictate.

      EDIT: I can see you are actually already listening on the Loopback adapter, but you create a Second L3 address and a corresponding NAT automatically - probably to avoid conflicts with other things listening on port 80/443... I think you should provide the option to just have the NAT forwarder listen on the LAN interface itself - without the need for a second L3 interface.

      I hope you can make sense of my request, and once again, thank you :-)

      Happy new Year

      Love the no fuss of using the official appliances :-)

      1 Reply Last reply Reply Quote 0
      • BBcan177B
        BBcan177 Moderator
        last edited by

        I have seen some mixed results with localhost. If you have all this issue, why don't you just add a new interface that is solely used for DNSBL.

        DNSBL requires a NAT/VIP since DNS requests that are blocked are destined for the DNSBL VIP on port 80/443.

        "Experience is something you don't get until just after you need it."

        Website: http://pfBlockerNG.com
        Twitter: @BBcan177  #pfBlockerNG
        Reddit: https://www.reddit.com/r/pfBlockerNG/new/

        1 Reply Last reply Reply Quote 0
        • keyserK
          keyser Rebel Alliance
          last edited by

          Hi BBCAN117

          Yes I thought about that as well, but that “complicates” the firewall unnecessarily in my opinion.

          Just out of curiosity - Why is a VIP address even needed?
          As far as I can tell there is no need to actually have the IP address to which the DNSBL requests resolves. fx:
          If the setup still required you to select an RFC1918 IP address that DNSBL would resolve to, making a destination NAT rule for that IP address on ports 80/443 should still work even if the IP address does not exist anywhere. So if the Webservice is listening on the Loopback adapter on 8081/8443 and the destination NAT portward points to that, It should work just fine. I have been using a setup with HAproxy listening on the loopback adapter with destination port NAT’s just like that for years without trouble.

          Hope this makes sense

          Love the no fuss of using the official appliances :-)

          1 Reply Last reply Reply Quote 0
          • BBcan177B
            BBcan177 Moderator
            last edited by

            That won't work for DNS requests from the pfSense box itself as those don't go thru NAT. I will do some more testing to see if there is anything else that can be done. But I still think you'd be better utilizing an isolated NIC.

            "Experience is something you don't get until just after you need it."

            Website: http://pfBlockerNG.com
            Twitter: @BBcan177  #pfBlockerNG
            Reddit: https://www.reddit.com/r/pfBlockerNG/new/

            1 Reply Last reply Reply Quote 0
            • keyserK
              keyser Rebel Alliance
              last edited by keyser

              My PFsense General setup page have DNS number one filled as 127.0.0.1 (being the UNBOUND resolver) and that works fine as UNBOUND also listens on loopback.

              So I don’t see how pfsense itself using the DNS could be a problem. Besides, the VIP address has no DNS service anf rules bound to it, so I cannot see What it brings on that account.

              Edit: And don’t get me wrong, I can work around the issue by either stop using the invert match rules or create a dedicated adapter for the VIP address.
              But I hate “un-neat” configurations and workaround solutions to something that could be solved SO much more clean and elegant if it was done just right (and following the guides of clean and effective network design).

              I love your work and you really are delivering the ONE package that makes PFsense a killer product. Your new -devel PFBlockerNG is just out of this world in ease of use and value :-)

              Love the no fuss of using the official appliances :-)

              BBcan177B 1 Reply Last reply Reply Quote 0
              • BBcan177B
                BBcan177 Moderator @keyser
                last edited by BBcan177

                @keyser said in DNSBL Listner IP casing serious Firewall issues:

                My PFsense General setup page have DNS number one filled as 127.0.0.1 (being the UNBOUND resolver) and that works fine as UNBOUND also listens on loopback.
                So I don’t see how pfsense itself using the DNS could be a problem. Besides, the VIP address has no DNS service anf rules bound to it, so I cannot see What it brings on that account.
                Edit: And don’t get me wrong, I can work around the issue by either stop using the invert match rules or create a dedicated adapter for the VIP address.
                But I hate “un-neat” configurations and workaround solutions to something that could be solved SO much more clean and elegant if it was done just right (and following the guides of clean and effective network design).

                Simple test.... you can see that if there is no VIP, when the pfSense box makes a request for a domain which is blocked via DNSBL, it will timeout looking for the DNSBL VIP address. This can be overcome by disabling logging in DNSBL which uses "0.0.0.0" instead.

                ifconfig em1
                inet 10.10.10.2 netmask 0xffffffff broadcast 10.10.10.2
                
                ping 101com.com
                PING 101com.com (10.10.10.2): 56 data bytes
                64 bytes from 10.10.10.2: icmp_seq=0 ttl=64 time=0.019 ms
                --- 101com.com ping statistics ---
                1 packets transmitted, 1 packets received, 0.0% packet loss
                round-trip min/avg/max/stddev = 0.019/0.019/0.019/0.000 ms
                
                ifconfig em1 inet 10.10.10.2 -alias
                
                ping 101com.com
                PING 101com.com (10.10.10.2): 56 data bytes
                --- 101com.com ping statistics ---
                8 packets transmitted, 0 packets received, 100.0% packet loss
                

                I love your work and you really are delivering the ONE package that makes PFsense a killer product. Your new -devel PFBlockerNG is just out of this world in ease of use and value :-)

                Thanks... If you want to help beta test shoot me an email (its in the General tab....) :)

                "Experience is something you don't get until just after you need it."

                Website: http://pfBlockerNG.com
                Twitter: @BBcan177  #pfBlockerNG
                Reddit: https://www.reddit.com/r/pfBlockerNG/new/

                1 Reply Last reply Reply Quote 0
                • keyserK
                  keyser Rebel Alliance
                  last edited by keyser

                  Hmm, I see.

                  edit: Or at least I think I see. In the above example it’s only timing out when actually trying to talk (ping) to the resolved address. The lookup works fine. I don’t really see why that is a big issue since talking to a blocked domainname from PFsense itself should not be necessary anyhow. I mean, that doesn’t work now with the VIP adress either. You are only talking with an “empty” replacement Weebservice that has no data. Is there any situation where you are depending on the firewall itself needs to be able to ping the address?

                  Anyhow

                  Two things:
                  1: Could this issue be solved by making a VIEW in UNBOUND so the PFsense box itself is in another VIEW Zone with no PFblock.conf attached?

                  2: Alternatively, could “disabling VIP Alias” also entail that the PFsense box itself then is setup to NOT use the build in UNBOUND resolver?

                  Love the no fuss of using the official appliances :-)

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post
                  Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.