Locking down public wifi vlan, only allow 80/443 web traffic. Two Rulesets
-
What is the difference between these two configurations?
Config #1:
Config #2:
-
The bottom rule: allowing anything destined for TENANT address is not the same as blocking anything not destined for TENANT address.
There is a default block all unseen at the end of every ruleset. So the block at the end of ruleset #2 is a bonus for your edification (and possibly logging control…)
The allow at the end of ruleset #1 actually allows traffic to TENANT address that would otherwise be blocked.
-
The bottom rule: allowing anything destined for TENANT address is not the same as blocking anything not destined for TENANT address.
There is a default block all unseen at the end of every ruleset. So the block at the end of ruleset #2 is a bonus for your edification (and possibly logging control…)
The allow at the end of ruleset #1 actually allows traffic to TENANT address that would otherwise be blocked.That's what I thought based on the "hint" at the bottom of the rules. Anyways, would the first configuration allow users of the TENANT subnet access to the web, dns, and dhcp. This is all I want to give them access to until I can get some appropriate traffic shaping and layer7 filtering to block p2p, etc.
-
Anyways, would the first configuration allow users of the TENANT subnet access to the web, dns, and dhcp?
For rules on the TENANT tab, sources "TENANT net" and source "*" are pretty much the same thing in practice. Any devices on that LAN port will have to be within "TENANT net" to talk successfully to the pfSense TENANT LAN address.
Ruleset #1: Yes, TENANT subnet users cannot talk to those other subnets (MANAGEMENT, OFFICE, SYNC) at all. They can talk to anywhere else (internet) on 80, 443 and 53. The last rule will let them (you) talk to the pfSense TENANT LAN IP on any port. Since you already allowed access to the webGUI (80+443) and DNS forwarder (53), I guess the last rule will also add access to things like SSH.
I just noticed that you selected protocol TCP/UDP. That means ICMP (ping) is not allowed. You won't be able to ping internet addresses for testing, or even ping TENANT address. If that is what you intended then fine, otherwise you might want to allow any protocol, or add an ICMP protocol rule.
-
DNS is included in the webports alias. I am actually unable to presently test this configuration from the perspective of the tenant vlan. however, would devices be allowed to respond to dhcp requests with this configuration? Is the last rule even required for what I am trying to accomplish. Oh and how effective is this from blocking individuals from any other traffic besides web browsing and email clients?
-
would devices be allowed to respond to dhcp requests with this configuration?
Yes, f you enable a DHCP Server on TENANT, then pfSense automatically adds the necessary rules to the packet filter to allow incoming DHCP requests from clients to work (you don't see the rules on the GUI, but they are there in /tmp/rules.debug)
Is the last rule even required for what I am trying to accomplish?
IMHO, no. The rules above it will let TENANT clients access the DNS forwarder on pfSense itself, which you want. They also let them get to the pfSense WebGUI login screen (you might want to block that, but then it is very annoying if you are on TENANT subnet yourself one day fault-finding and you can't access the WebGUI to see what is going on!)
The bottom rule will let them get to all ports on pfSense TENANT IP - that would include trying SSH login (if you have that enabled on your box).
Net result: I think the bottom rule can be removed.how effective is this from blocking individuals from any other traffic besides web browsing and email clients?
Seems good to me - the packet filter will certainly do the job and dump stuff destined to other ports. It might be a bit/lot annoying for the "tenants". e.g. they can't OpenVPN to port 1194 or whatever outside. That really annoyed me when I was staying with some friends who teach at a boarding school. The internal school network had this sort of locking down of ports, so I couldn't establish VPN links from my laptop at their residence in the school, out to my office. (Thankfully TeamViewer found its way through)