Need help with a firewall rule to allow PiHole DNS and block users from accessing the PiHole GUI....
-
@Ghost-0
Which pfSense interfaces are the devices connected to?
If they are connected to the common wifi there is nothing you can do on pfSense to block the access. -
@viragomann
Both PiHole and the UniFi controller are on the Raspberry Pi server, which is connected via LAN #1 (Igb1). I have two LANS and several subnets. The whole house is wired for Cat6 and have three UAP's (UAP-AC-PRO x 2 & UAP-AC-long range). -
@Ghost-0 while that is good info, not really what he asked. If your pihole is on a different vlan than your clients you want to stop from talking to the pihole gui, then pfsense can be used to prevent access to the gui.
But if clients are on the same network/vlan as the pihole then pfsense is not involved in that conversation and can not prevent something on the same network from talking to another than on that network.
-
@Ghost-0
So you can simply block the access on the wifi interface.If you don't need any access from the wifi to the Plans consider it only allow public destinations + DNS. Means, allow only what you really need.
Or even add a block rule for the destinations of the pinhole and the cloud key.
Then add a pass rule for DNS and put it above of the block rule. -
I'm sorry! I'm an advanced newbie when it comes to network stuff. PiHole is on the main LAN. It is not on any VLAN's. No servers or critical resources running on VLAN's. The VLANS of my network are used primarily for network segmentation, e.g, IoT's, WiFi access; cams (protection from cheap Chinese cams), etc. -
@viragomann
That sounds great... I'm going to implement your suggestion and let you know how it went. By the way, I'm not using the UniFi cloud key. The UniFi controller is self-hosted on my cheap & yet powerful Raspberry Pi 4.
I just got this Raspberry Pi. I had to wait almost two years for a reasonably priced one due to the post pandemic supply-chain issues and greedy vendors. 
How would you implement this rule? Could you write one as an example for me because I failed several times already.
-
@Ghost-0 said in Need help with a firewall rule to allow PiHole DNS and block users from accessing the PiHole GUI....:
PiHole is on the main LAN
And who/what do you want to block from talking to the gui, if on the main lan pfsense can not help you - if devices/clients/whatever are on your other vlans then yes you can prevent them from talking to the pfsense gui but allow dns via simple firewall rules.
-
This post is deleted! -
The issue is not experienced on the main LAN. I'm only experiencing it on the VLANS except the guest vlans, which is controlled by the UniFI Guest Captive portal. The guest vlan works as expected because it is under the control of the UniFi captive portal. The issue is on the other vlans. I don't want them to have access to the GUI of both PiHole and the UniFi controller. I just want those vlans for internet access/ DNS. I have my own private recursive DNS server on Raspberry Pi. It is unbound combined with PiHole. Please give me a specific rule that allows DNS and blocks access to GUI of those resources on the VLANs. Again, the LAN side doesn't have this issue. The DNS server and the UniFi controller reside on the LAN. Thanks for you help!
-
@Ghost-0 you allow dns tcp/udp 53.. And right below that block whatever the gui ports are running for your pihole.. This is normally just port 80, unless you setup https on it.. But block both 80/443 or just completely block everything else to your pihole IP.. All that is need for dns is 53.
edit example of a locked down vlan - change the IP of pihole to what yours is.. It allow dns, but then that rule below that blocks all other access to any other rf1918 would block access to the gui.
This is basic 101 firewall stuff here.. Rules evaluated top down, first rule to trigger wins no other rules evaluated. You put your allow above your denies..
If you want to allow other stuff to your other networks from your locked down network, put them above the rule that blocks to rfc1918 space.
-
Thanks for addressing my issue and for the quick reply. Love the way you listed the sample rules. Could you please define the following for me in more details:
- "test subnets"... Is that from the dropdown list from the source section, for example one of the vlans that populate from that dropdown list for me is named Iot.net and IoT address. Which one do I select for the very first rule (ICMP). There is no option for IP for that rule, how is pinging possible for that rule?
Block rules usually have a red X for me. I don't see that in your sample rules; they seem to be yellow in color from your sample rules. I'm using pfSense 2.7 (AMD64.) Is that because you are using a different version? I may have additional questions once the above ones are answered. Thanks for your patience with a newbie!
-
@Ghost-0 locally its common to use reject other than block.. This rejects it vs just ignoring it - so the client knows hey not getting there no need to wait and send a retrans..
You can use either block or reject, but locally is normally better to just use reject. I wouldn't use say reject on your wan.. But locally its nice to just let your local clients you ain't getting there no need to send retrans.
Yes the source would be whatever network your setting the rules for on the interface. Unless this was a transit network, source would be the network the interface is connected too. Mine is called test because this is really only an interface I use for showing users rules.
Ping is icmp, not sure I understand the question to be honest allowing ping would be the icmp protocol, not tcp or udp.
-
My last post was premature because your sample rules work after taking a detailed second look. I would have never figured it out without your help. It is so complicated. I copied your rules and my system is working like I want it. You are the man! I really appreciate your help. I wish I had your network skill set. Again, thanks for your help!! 
P.S. I may have another critical pfSense issue for you to solve since you seem knowledgeable regarding psSense.
Happy Holidays
-
@Ghost-0 said in Need help with a firewall rule to allow PiHole DNS and block users from accessing the PiHole GUI....:
I may have another critical pfSense issue for you to solve
Happy to help..
It might look complicated, but just take them one rule at a time.. Rules are evaluated top down, when a rule triggers (ie matches) no other rules are looked at. So follow your rules down and you can figure out where you need to place your rules. And just remember if traffic never matches anything and it gets to the end not being allowed, the default deny will block..
You wouldn't need that block rfc1918 rule for example - except you have that last rule that allows anything, ie the internet. So before you allow that you need to say, hey you can't go to any other rfc1918 network. This is what blocks talking to your pihole web gui.
-
@Ghost-0
I'm kindly asking you to review a recent post that I posted earlier today, regarding another pfSense issue that I have been experiencing for years. Please review it and let me know of a possible solution. Again, thanks for everything! -
@johnpoz
I beg to differ. It is complicated for me. My pfSense rule skill set is very rudimentary. Your sample rules reveal new ideas to me. I didn't know you could add ICMP, NTP, etc in the pfSense firewall. I thought these things were only available in Microsoft windows. Your sample rules are an eye-opener. This has inspired me to embark on a pfSense journey for more knowledge. -
I have a question for you. I don't really understand this pfSense firewall rule option, invert match, please define it for me in simple terms.
-
@Ghost-0 said in Need help with a firewall rule to allow PiHole DNS and block users from accessing the PiHole GUI....:
invert match, please define it for me in simple terms.
It means exactly that in my rule where I allowed dns to 192.168.3.10, the rule would match if it was any other than 192.168.3.10.. Invert rules are rarely needed, if ever to be honest. You should prob just forget the option even exists.. Just be very explicit with an allow to what exactly you want.
While they might be useful in some complicated rule sets, your typical user should really never have need for them.. And there have been problems in the past where if you had a vip setup it could be confused.. If you do plan on playing with invert or ! rules - make sure you extensively test that is working as you intended.
Yes you can get specific with your ports, and with your protocols.. Just look at your rules line by line and what traffic you want to allow or block. Source IP, destination IP, port and protocol (tcp/udp/icmp/etc) does the rule allow it or deny it. As you walk through your rules top down.. If you get to rule that matches, no other rules will be looked at.
-
@johnpoz
Thanks for the explanation! Some users on YouTube use it extensively. To me it is not intuitive. I find that option confusing. I thought I was missing out. Now I feel better after your explanation. -
I have done extensive testing of the firewall and found no leaks after implanting your suggested rules; pfSense appears to be functioning as intended. However, I had to make a slight modification of one of your rules to accommodate the Unifi Captive Guest Portal on one of the subnets. The issue was connected hosts were unable to access the captive portal web page. Rule #2 of your sample rules had to be modified: "Source, test subnets" was changed to "any" and port 53(DNS) was changed to no port.
