Blocking VLAN access to firewall and other vlans
-
@parry said in Blocking VLAN access to firewall and other vlans:
I can't ping the DNS server address which is assigned to 192.168.vid.1 address on each vlan by dhcp
Where in your rules do you allow that? I don't see anything that would allow you access - you specifically block access to "this firewall" which would be anything pfsense is running... Other than dhcp which is enabled by hidden rules when you enable it.
Here is sample setup of locked down vlan..
I allow clients to ping pfsense - to validate connectivity.
I allow clients to talk to dns on that vlan, the "test address" port 53 tcp and udp
I allow clients to use ntp to pfsense IP address on that vlan
I then block all access to any other pfsense IP.
I then block all access to any other vlan (rfc1918).. Alias created that includes all rfc1918 space. (see below image)
Anything else they can do - ie internet..Rules are evaluated top down, first rule to trigger wins, no other rules are evaluated. If you want a client on vlan X to use dns of pfsense, then you need to allow that - before you block all access to any IP on pfsense.
here is my rfc1918 alias - all my vlans would be using rfc1918 space ;)
If you don't want to block all vlans - then you could just block the "net" addess of your other vlans you don't want to allow access to.
-
@johnpoz Ahem ... again. Yours is a very usefull answer... I see where I went wrong, I assumed that "This Firewall" meant that I should not be able to access the firewall, not the routes through it. Although yes, I did see the statement you made which was that "this firewall" should include all address on all interfaces in pfsense yes.."
So with the information you provided I understand what is going wrong. I'm blocking all access to the firewall so I can't get a DNS address resolved. Allowing the DNS port 53 access fixes the problem. However why is it that I can get through the firewall to the internet if everything is blocked on all addresses and interfaces. Is there something more sophisticated about "This Firewall" than it simply blocks everything ? My next steps will be to follow your useful posting, Ta very much jonhpoz . Deny first and by default ;) -
@parry said in Blocking VLAN access to firewall and other vlans:
However why is it that I can get through the firewall to the internet if everything is blocked on all addresses and interfaces
Because your destination is not a pfsense address - so that rule doesn't trigger, and then you have a rule that is allow any.. Say 8.8.8.8 for example, or any other public IP on the internet.
-
@johnpoz I guess I am in denial ;) At least should see what is being denied. before acknowledging its denial ! These subtleties (which probably seem like big bricks to you) require a thinking in reverse. If it aint explicit, it's denied. I guess it is my last rule "Default allow VLAN4 to any rule" that allows the vlan to access the internet why would that not also allow port 53 access. What I am getting at is what in "This Firewall" is blocking port 53 access. Conversely if the answer is "default is deny" then why does my last explicit rule not permit port 53 access ? In the end what is "This Firewall" composed of. Or am I barking up the wrong aspidistra (which keeps flying).
Tx johnpoz -
@parry said in Blocking VLAN access to firewall and other vlans:
"default is deny" then why does my last explicit rule not permit port 53 access ?
Because you denied IT above - never got to the any rule.. As I stated rules are evaluated top down.. First rule to trigger wins - NO OTHER rules are evaluated..
So if your trying to to access pfsense IP on any port, say 53.. And the rule says blocked - it stops looking at the other rules.. So it never gets to your any any rule.
In the end what is "This Firewall" composed of.
Every IP assigned to an interface on pfsense.. The lan, the wan, optX, vlan 42 - any interface on pfsense that has IP on it - that is what "this firewall" is.. Its a great rule to use to keep say users from access your wan IP (public) -- that could change.. Since your normally allow any for internet.. Well the public wan IP of pfsense would fall into that.. So using "this firewall" is a way to make sure say your guest wifi client can not access your pfsense web gui from the guest vlan.. But he can access anything else on the internet.
Or maybe you want client on vlan A to be able to talk to clients in vlan B, but you don't want him to be able to hit web gui on vlan B of pfsense.. But if you allowed access to vlan B net - the pfsense IP of vlan B would be included in that, etc.
-
@johnpoz Many thanks. I now have the firewall working exactly as I need. A couple of questions. (1) Apart from monitoring the firewall data, perhaps capturing all of the data and analysing it in wireshark, is there any software such that if I take the xml file which contains the firewall rules, then entering an ip address and port number and network interface, I could see the result of trying to get the message from that location/port to a destination that is on one side or the other of a firewall. Basically it would immediately show me where the problem is. For yourself that is immediately obvious so you would not need it, but for others it might be useful
(2)Do you know what the benefit of purchasing a Netgate device to do this is ?
-
I am not aware of any tool for pfsense firewall rules that could parse them and show you which rule would trigger on a set of inputs.
As to purchase netgate appliance? Its good hardware at a reasonable price. You are 100% sure its going to work with pfsense ;) They stand by the hardware they sell for sure. Netgate appliances run + vs ce, which comes with some benefits like specific packages that are not available in ce. Be it you have use of those would depend on your use case.
You also are supporting pfsense when you buy netgate.. Which is added plus for sure.
I ran pfsense on VM for many years, and over the years on diy hardware.. I don't ever see going back to that.. Love my sg4860.. And when its time to retire or dies there will for sure be another netgate appliance to replace it.
All that being said there are many people that run pfsense on their own hardware or VMs. Its not like you have to run it on netgate hardware if you don't want to.
-
@johnpoz - that's the best, most clear answer to a forum question I've ever seen! Love the screenshots of example entries, makes it very clear! Thank you!
I had exactly the same question and requirement as the OP and after following your advice here, all works as required!
I added a couple of extra additional rules in my list:
1 - the pfblocker NG rule which is added by default when implementing pfBlockerNG
2 - a rule that prevents access to the web admin of pfsense on each interfaceCould any of this be done more efficiently (for example, some rules grouped in Interface Groups)?
-
@lees said in Blocking VLAN access to firewall and other vlans:
Could any of this be done more efficiently (for example, some rules grouped in Interface Groups)?
Why do people think less rules, harder to read is more efficient. Do you have 100 different interfaces you need to place these rules on? If not manage the rules per interface - grouping is only going to confuse what is what..
You know what is efficient - being able to instantly look at an interface and understand the rule set on what is allowed or blocked in a few seconds. Vs having to go look and see what group, or what interface this applied to in floating what direction, etc..
No grouping, no ! rules for what make it harder you to understand what rule is being applied?
If you had 1000 different interfaces to manage, and most of them had the same rules on them - ok sure figure out some shortcuts to apply the rules to all the interfaces.. When you have a handful - just apply them.. Take you what 30 seconds? You know you can copy a rule from interface to other interface - just changing the couple of things right..
For your ruleset I would place allow before block.. If you know you want to be able to ping pfsense IP, then that should be above where you have a block rule that is all of IPv4 and automated alias that for you know could at some point include your local IP range..
-
@johnpoz thanks for your reply!
I guess there's a lot of discussions in the forum about making rule creation as easy and as efficient as possible, and that aliases and groups are one way of doing that, hence my question
Yes indeed, the copy rule function does make it a lot easier to adapt existing rules to other interfaces.
I have about 15 VLAN's (for various reasons), and some would say that is way too many (but they don't know the circumstances of course). But even 15 is easier to manage with a handfull of rules like this.
So thanks again for your helpful insight!
-
@lees I have 8 vlans.. While it would take a few minutes to setup.. To be honest its way faster to just do it vs trying figure out what interface belongs in this group, what interface belongs in that group, etc..
15 does seem like a lot of a home setup, for a even a small business sure could see that many easy, etc.