Blocking VLAN access to firewall and other vlans

[parry]

I have a number of vlans none of which should access the main LAN 192.168.1.0/24. My rules are in order of priority (a) Block VLAN to Lan.net (b)Block vlan.net access to 'This Firewall" and then (c)Allow vlan.net access to any, All vlans have access to their DHCP servers in pfsense and for some reason can access the pfsense firewall at 192.168.vid.1. I had thought that the use of "this firewall" as a destination would prevent any access to the firewall from any subnet. Yet it seems I am doing something wrong as the firewall is accessible from and address such as 192.168.4.1 which is accessible from vlan4. Any insights welcome.

[johnpoz]

@parry could you post up your actual rules..

"this firewall" should include all address on all interfaces in pfsense yes..

Make sure you killed any existing states when adding block rules - and existing state would allow traffic until that state goes away, either times out, closed or killed.

dhcp is allowed via hidden rules, when you enable dhcp on an interface.

[parry]

@johnpoz Thanks lad for responding. Here are my rules on one vlan
With this ruleset I can't ping the LAN, I can't ssh into it nor can I reach a webserver on that lan. I cant ssh into pfsense on the 21 vid as in 192.168.21.1 but I can reach it on https://192.168.21.1. However one of the things you said made me wonder - that of killing existing states. After I poked around the vlan- trying to ping, ssh and access a server on the vlan, access to the firewall stopped. However I lost DNS(using resolver on 2.4.5) but could ping an external ip address as long as I was not asking for DNS resolution. dig does not provide a response

Here's another example, slightly different - on this vlan I am blocking a number of test phones with specific ip addresses but the following sequences are the same. .
As long as I reload the same page showing these rules, I can get back to them. However in this case, as on VLAN21 above VLAN4 DNS stops working, but I can ping an address outside the firewall such as 1.1.1.1.
As before dig does not provide a response. Since my network has pfsense --> basic unmanaged switch ---> Freshtomato wifi router (Wan is disabled) connecting to this device over 802.11 is it possible that there is something about the states in the different components that are not moving on to the new state. More importantly is there a clear way of killing existing states in pfsense other than reloading the filter ?
Thanks again for bothering to respond.

[johnpoz]

@parry why would you be blocking bogon on lan side interface... Big no no for sure.. Clearly states it right there were you would enable it

[parry]

@johnpoz Ahem
To be perfectly honest, I think it appeared a long time ago in some kind of automated setup (this is in the mists of time when I was learning about pfsense) and then reading what it says "Bogons are prefixes that should never appear in the Internet routing table, and so should not appear as the source address in any packets received I then followed this logic. If these should not appear, I figured I could prevent any that did and hence blocked them.** Remarkably, reading this statement - as in this stuff should not show up led me to not read the following sentence that you marked in yellow. Strange isn't it ;) The power of a strong phrase. So having removed this setting all appears well. Thank you. @johnpoz

[johnpoz]

@parry Also keep in mind that default is deny.. If some odd ball source IP tried to talk to pfsense interface XYZ on your local side. It wouldn't be allowed anyway - since your rules clearly stated source being vlan 4 "net" so if the source IP is not part of vlan 4 network - it would be dropped by the default deny rule anyway.

[parry]

@johnpoz Default is deny.. Sounds like a religion ;) Thanks again..

[parry]

@parry Unfortunately, after waiting another few minutes I am back in the same situation with the VLANs being blocked from accessing DNS. I can't ping the DNS server address which is assigned to 192.168.vid.1 address on each vlan by dhcp I moved my laptop to the output of the pfsense box which is an ethernet port used as a trunk for the LAN and 4 other VLANs to avoid any issues with the intervening switch and Wifi Routers. I get the same problem, that is I cannot reach the internet / DNS with a DHCP acquired address. Since I can ping any external IP address directly and if I assign an external DNS ip address such as 1.1.1.1 to my client, rather than letting DHCP assign it, I can access the internet. At this point I thought that it seemed that the pfsense DNS resolver somehow is not providing a resolved IP address. My firewall rules are as above for each vlan and I removed the block bogon option. Sorry to return with bad news, but I think I can rule out any switches or wifi routers as the problem and based on the informtion above it seems somehow DNS or some other rule is involved. If I set DNS forwarding in the resolver as in https://docs.netgate.com/pfsense/en/latest/services/dns/resolver.html I still don't get access to DNS, while being able to ping any specific internet ip address. The only thing I can think is causing this is the block to "This Firewall". I base this on (a) The fact that if I explictly add an IP address for DNS in my client I get name resolution (b) Forwarding the DNS request to a specific IP address such as 1.1.1.1 in the DNS resolver and setting up the DNS server in the general setting does not help with the resolution of names. Again any insights you can provide would be really useful. Sorry that my high hopes were dashed and I had to come back for more advice. By the way I do not use dnssec. Thank you. parry

[johnpoz]

@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.

[parry]

@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 ;)

[johnpoz]

@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.

[parry]

@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

[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.

[parry]

@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 ?

[johnpoz]

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.

[LeeS]

@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 interface

Could any of this be done more efficiently (for example, some rules grouped in Interface Groups)?

[johnpoz]

@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..

[LeeS]

@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!

[johnpoz]

@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.