Unbound on local LAN and IP blocking
-
I have being running Unbound DNS in Docker on my Synology NAS for 2 years. Its rock solid, I can compile and update to new version myself. I use Response Policy Zones extensively. This thing never gives me any issue and runs 24/7. I would like to keep it that way. My RPZ files are updated daily and ads blocking works for my LAN – no issues here.
I just got my hands on used Netgate 5100 and would like to configure it so it is using my current Unbound instance as DNS for all my LAN segments. I also want to block certain IP’s. In my current design I have a custom firewall code running on my main router and using IP lists from iplists.firehol.org to block many IP’s (ingress and egress).
I am wondering if anyone can suggest best approach to accomplish my requirements.
From what I could learn, the pfBlockerNG does both – which I do not like. IP filtering should be done by a firewall. CNAME blocking belongs to DNS. Two different services and if separate easer to manage.
I could not find any documentation about blocking/filtering IP lists without using pfBlockerNG.
I appreciate any suggections.
-
@markster you can create you own lists via aliases in pfsense, and then use them in your firewall rules.
pfblocker doesn't actually do any blocking in the firewall, it just creates rules that it uses its aliases with. Or blocks user from looking up something.
You can just use pfblocker to maintain your native aliases and manually put them in your rules - this is what I do. I don't like anything creating automatic firewall rules.
https://docs.netgate.com/pfsense/en/latest/firewall/aliases.html#aliases
-
@johnpoz - thanks. Looking closer, using URL Alises will give me what I need. But, it would not refresh the lists.
It looks as if this is one time import only. I could write a shell script to re-import each list and use cron I suppose.If I decide to use pfBlockerNG for IP fitering config and lists refresh, ( this is spare me from writting the shell script to refresh URL Aliases) does it require Unbound DNS to be installed on pfsense?
How would I configure pfsense to redirect all DNS to my current Unbound DNS? Any suggestions?
Do I specify DNS IP of my DNS for every interface I confifgure or is there a better option? -
@markster said in Unbound on local LAN and IP blocking:
But, it would not refresh the lists
sure it does.. You set how often.
The min is once every day. If you want more often than that, you could use pfblocker to maintain your aliases.
How would I configure pfsense to redirect all DNS to my current Unbound DNS? Any suggestions?
Just like how you redirect to pfsense but have it sent to your local dns.
https://docs.netgate.com/pfsense/en/latest/recipes/dns-redirect.html#redirecting-client-dns-requests
Keep in mind if the dns is on the same network as you clients you could run into some issues.
pi@pi-ntp:~ $ dig @8.8.8.8 www.google.com ;; reply from unexpected source: 192.168.3.10#53, expected 8.8.8.8#53
As you see above I redirected dns to my pihole, but the client is on the same network as the dns.. So dig for example says hey wait I asked 8.8.8.8 why is 192.168.3.10 sending me an answer. If your clients are on a different network/vlan than your dns he wouldn't know that pihole answered him. If on the same network you would have to do a extra nat thing.
to be honest its better to set your clients to what they should use for dns directly vs having to redirect all their traffic.
-
Thanks @johnpoz . That will definitly do for my use case.
Since I am new at this - I am getting my unit next week - how would I implement a firewall rule to block ingres and engress WAN traffic with URL Table like this?
Thanks again for your help.
-
@markster so you have some table with IPs or networks it.. If you wanted to stop those ips/network from getting to your port forwards would be that above your port forward allow rules on your wan. With that alias as source.
If you wanted your clients to not to be able to go there, then you would put that rule above your any any default lan rules.
You can also do out rules on floating tab.. But I would really suggest you just use the specific interfaces directly vs playing with floating - floating is for when you want to do fancier stuff.. Keep it simple, put the rules on your interfaces. At least until you more comfortable with doing rules.
Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated as traffic enters an interface from the network its attached to.
Keep in mind for inbound rules into you want, the default is deny all.. So unless your allowing some sort of traffic to your wan, or port forwarding to something behind pfsense. The wan rule blocking a list of IPs/Networks is pretty pointless on the wan.. Unless your looking to say not log that, or you turn off default logging and only want stuff in this alias logged, etc.
-
@johnpoz Thanks. WAN IP blocking does not make sense. I agree with you. I do have port forwarding enabled on my LAN.
So, the question is which is best. Blocking bad ipsets under LAN section or would it be better to use Floating Rules?
I have multiple segments so I created LAN group and applied DROP rules there for now. I am using few firehol IP lists.
Since the rules are applied to internal LAN(S) the rule is to DROP any LAN traffic with Destinations matching the IPSET listing (BAD IP's)
I still wonder if it will be more efficient to have these rules in Floating Rule section.
-
@markster said in Unbound on local LAN and IP blocking:
So, the question is which is best. Blocking bad ipsets under LAN section or would it be better to use Floating Rules?
I regularly advise in pfSense related workshops to NOT use floating rules if you aren't absolutely sure what you are doing. Many things can just go wrong with "experimentation" as floatings won't work like normal rules (e.g. quick, in/out, etc.)
So if you are unsure - avoid until you know exactly what you're doing. Too often we are called for audits of boxes that simply allow too much traffic or were secure until someone created a rule in floatings without others noticing and simply allowing way too much more than wanted/needed.So to tackle your question: blocking IPs on WAN can make sense if you have services you want to protect (e.g. VPN access etc.) and want to block known bad-IPs from it. Or to simply sort out those known bad-IPs from the logs.
For multiple LAN/VLANs that do outgoing traffic, your take is pretty damn good and what I'd suggest. If you have multiple Interfaces that do essentially the same traffic (multiple client LANs, VLANs, web access etc.) and you can be sure your lists don't accidentally block internally used IP ranges - fire them into a LAN Group and reject it (that's more friendly inhouse as your clients get it more quickly, that a connection has been rejected then if it has been silently dropped and they run into a timeout).
Also check your rules for the "source". If you group multiple LAN/VLANs together in that IF Group, make sure you put all source IP ranges into an alias you used as source or use "any". As the target IPs should be external anyway that shouldn't hurt internal traffic. If you use pfBlockerNG to pull firehol1/2 you're pretty safe but if you fetch it manually be aware that firehol1 commonly has RFC1918 private IP space, Multicast and APIPA spaces listed and blocked so without pfBlocker pulling and supressing local networks you could run into problems.
If not sure, just show a few screenshots and we'll have a look :)Just a sidenote: don't group multiple WANs that way (as WANs have a bit of special handling when it comes to incoming traffic and gateway handling) .
Cheers!
-
@jegr Thanks for the suggestions. I dont use pfBlockerNG since I have my own Unbund DNS running on my network in Docker on Synology. This way I am able to stay most current with Unbound versions. Big plus is that I am able to use Unbound full API when it comes to RZP and dns trigger actions. pfBlockerNG is not near what pure Unbound can provide in functionality.
AS I mentioned I do have port forward enabled and multiple interfaces. I use firehol ipset level2 and 3 plus some additional ipsets. I block these aliases at the interface group level.
These are configured to block any internal traffic going OUT to any of the IP in these lists.Running it about a week and I have few hits. Its a low count.
That proves to me that it is working and catching bad actors as it should.