Simplied method of preventing inter-VLAN communication
-
@appleguy no - rules are evaluated top down, first rule to trigger wins and no other rules are evaluated.
If your dns is say 10.0.100.1 which is rfc1918 your first rule would prevent that access. So no dns.
edit - now that is wrong as well, since your block rules are below where you allow everything. Order matters..
-
@appleguy yeah this better.. But not sure why your using "this firewall" for dns - while that can work.. Are you devices going to use every possible pfsense IP, or just the IP on that interface?
Normally you would only allow this network to talk to the IP of pfsense on that network for dns and ntp, ping, etc.
-
@johnpoz oh no, so change this firewall back to 10.0.100.1 on the first 3 rules? I think I need to allow for DHCP on the router too?
-
@appleguy depends on what you want.. But your first rules should allow for dns and anything else you want to be allowed to the IP of pfsense on this interface. If you don't care about pinging pfsense, or ntp or even dns then that is not needed.
But normally clients only "need" to talk to 1 IP of pfsense, normally the IP of pfsense on that interface - "this firewall" is all IPs of pfsense, other vlans/networks - the wan IP, etc.
Its odd your not showing any hits on those rules 0/0 if you were actually using a Pfsense IP for dns - those should show some hits. Mine are all 0/0 on my test interface. Because I only use that interface for showing rules, etc. I don't really have a test network ;)
-
@johnpoz here is an actual network of mine with devices on it.
Notice my rule for dns is any for destination - I don't care where they talk for dns, which could be pfsense IP on this guest network or it might be 8.8.8.8 for example..
But see the order, I allow stuff I want that could be rfc1918 before I block rfc1918. In this case the "this firewall" rule is preventing access to say pfsense wan IP for the gui port or ssh, etc.
Just remember top down, first rule to trigger wins. Walk down your rules on what you want to allow, what you want to block, walking through the rules to see which rule would trigger..
In the case of these rules - I could prob just use wan address vs "this firewall" since what worried about is guest accessing say the public IP of pfsense for gui or ssh, all other IPs of pfsense are rfc1918.
-
@johnpoz ok, loosened some back up a little. don't see any default rules for DHCP in protocols so DHCP should still work? I do DNS and DHCP from pfsense.
-
@appleguy dhcp is a hidden rule when you enable dhcp on an interface.
-
@appleguy said in Simplied method of preventing inter-VLAN communication:
@johnpoz ok, loosened some back up a little. don't see any default rules for DHCP in protocols so DHCP should still work? I do DNS and DHCP from pfsense.
@appleguy First three rules just need "CRYPTO addr" not "*" - no need for any in that case, as you'd normally only want them to reach pfSense for DNS and NTP or PING and leave anything other closed.
-
@jegr thanks again for all your help! finally got it right! wait, not *? does not mean inverted?
-
@johnpoz Is there a way to see the hidden rules? I've never really considered that there would be Firewall rules set up on an interface that we didn't know about. I've wondered from time to time how DHCP works even though traffic is denied.
-
@appleguy This is how I have all my ports/VLANs set up by default. Similar to yours but I specify the destination and use external NTP.
It's interesting to go back and see. Nothing's pinging the firewall or using DNS on this VLAN. That's OK. Nothing trying to get into the firewall. Also good. But something is trying to access other local IPs outside of the subnet? What're those cameras up to, I wonder? Glad I've got that block!
-
@stewart I like the vlan id in the name! gonna do that too
-
@appleguy Makes it so much easier when you do that everywhere, even in the switches. You have full visibility and know right where you are instead of constantly needing to cross reference.
-
@stewart said in Simplied method of preventing inter-VLAN communication:
there a way to see the hidden rules?
yeah.. here
https://docs.netgate.com/pfsense/en/latest/firewall/pf-ruleset.html#viewing-the-pf-ruleset
While I agree I would love to be able to see all rules in the gui. I think they do it because users can't seem to understand inbound and outbound on an interface or that rules need to be in a specific order, etc etc.. - not specifically directed at you, just a general comment ;)
So if there is a way to keep the user from shooting themselves in the foot so be it.. dhcp can be a complicated protocol with the 2 different ports involved and source IP and broadcast, etc.. So just doing that for the user when they enable dhcp on an interface keeps the why is it not working threads down to be honest ;)
The antilock out rule for example - that would cause some grief for sure if that wasn't there ;)
They should prob setup a auto hidden rule to allow for dns to the interface IP when you have unbound listen on that interface as well ;) same with ntp..
-
@johnpoz I'll check that out. Maybe if there were an advanced button that showed the additional rules, or showed the rules and made them so they couldn't delete or modify them. It sticks in the back of my mind that if there could be hidden rules then could there be an exploit in the future that modifies or adds hidden rules and we wouldn't ever know since they don't show in the rule list.
-
@stewart Why not just show them like the block rfc and bogons?
-
@jarhead The difference I see is that those are things we add in ourselves via the interfaces tab whereas these rules always exist and are automatically created by the system, but that's essentially what I'm suggesting. Just have them show up but limit what we can do with them. If they want to keep them hidden then tuck them behind an advanced button or maybe an expandable section at the bottom of the page.
-
@stewart said in Simplied method of preventing inter-VLAN communication:
could there be an exploit in the future that modifies or adds hidden rules and we wouldn't ever know since they don't show in the rule list.
While that is not out of the realm possibilities I guess.. if your pfsense was compromised in such a way that they were altering hidden rules.. What stops them from just not showing the rules they create in the first place, even if gui was set to show them ;)
My take, and this is just from a user point of view, and long time one at that is they hide the rules that just keep users from shooting themselves in the foot. Like the dhcp ones, there are some other hidden rules to make sure stuff works in the background - again keeping users from shooting themselves in the foot is my take.
While I agree I would like to see a button or something I could push to show all rules.. Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@johnpoz said in Simplied method of preventing inter-VLAN communication:
While I agree I would like to see a button or something I could push to show all rules.. Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.
I agree with most of John's post.
Just for the record without following the link: Just run a
cat /tmp/rules.debugin either the shell, via SSH or via Diagnostics/Command Prompt to see the full scale loaded ruleset (or uselessinstead ofcatif you're on a real shell/SSH to view it without it scrolling past you).Most that check the content of the file will understand, that displaying the full ruleset could be very confusing to users. E.g. OPNsense has that button to show hidden rules and most comments after they included it were "do I really need those, where can I disable XY, etc. " when try introduced it, not understanding, that those are indeed necessary for normal operations. I'm absolutely pro-button to show them, but I also can 100% understand to hide them / make them invisible to stop tampering. People get extremely creative when things won't work and more times then not I've seen configs tampered with and explained by "things didn't work and the switches didn't to what I wanted so I edited the config..." - yeah, no, that didn't work out either
Cheers
-
@johnpoz said in Simplied method of preventing inter-VLAN communication:
While that is not out of the realm possibilities I guess.. if your pfsense was compromised in such a way that they were altering hidden rules.. What stops them from just not showing the rules they create in the first place, even if gui was set to show them ;)
That appears to be along the lines of "Why implement this security if it can theoretically be bypassed?" I'd argue that the additional measures are worth it even if it could be bypassed. Maybe the "Button" would just run the 'cat /tmp/rules.debug' and display it in an embedded window.
@johnpoz said in Simplied method of preventing inter-VLAN communication:
My take, and this is just from a user point of view, and long time one at that is they hide the rules that just keep users from shooting themselves in the foot. Like the dhcp ones, there are some other hidden rules to make sure stuff works in the background - again keeping users from shooting themselves in the foot is my take.
I guess my next question would be, how does this compare to other vendors? I've not seen rules like these in other products (Cisco, Sonicwall, Fortinet) that I can recall and certainly not in soho devices. Is it normal to have hidden rules like that?
@johnpoz said in Simplied method of preventing inter-VLAN communication:
Anyone with enough skill to want to actually view the full rules list, and understand what they mean can for sure very easy seem them if they want to with the link I provided above.
I didn't even think that there would be other rules so I never went out to check to see if there was a process to run to look for them. I would think a great deal many people would be in the same boat which is why I would advocate for some form of visibility on the page. Sure, once we know then we know and can check, but until this thread I had no idea there would be hidden rules so I never would have gone to check for them.
