DNSBL Listner IP casing serious Firewall issues

keyser

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

BBcan177

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.

keyser

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

BBcan177

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.

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 :-)

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....) :)

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?