reboot required to add VLAN?
-
This is the second time I have had this happen to me: I add a new VLAN, assign the interface an IP, enable DHCP, and test. At this point all is well, devices on the VLAN get an IP. But what doesn't work are firewall rules.
Just to rule out the possibility rule mis-configuration, I disabled all rules on this VLAN and set a basic DENY ALL ANY/ANY rule. And yet, traffic is still allowed to pass.
The last time this happened to me I had to reboot pfSense and then everything worked as expected. I can't reboot in the middle of the workday so I have a cron job scheduled to reboot at 3AM tonight and will check back tomorrow.
My question is: is a reboot required after adding a new VLAN in order for the firewall rules to kick in? Or is this some kind of other fluke / bug? I can't seem to find anything in the documentation about a reboot being required but that seems to be my experience.
-
@aaronssh said in reboot required to add VLAN?:
DENY ALL ANY/ANY rule. And yet, traffic is still allowed to pass.
And if there were states that allowed traffic then it would be allowed by the state.
No a reboot is not required after adding interfaces or vlans.. But you have to understand rules..
When you create a new interface or vlan there will be no rule... If you add a allow rule, and a state is created.. And then create a deny rule - the state has already been created when your allow rule would still allow the traffic.
You need to clear the states that are created that are allowing traffic, or you need to wait til they expire. Rebooting sure is one way to do that - but its a bit of overkill, like burning down your house to get rid of a spider ;)
https://docs.netgate.com/pfsense/en/latest/troubleshooting/firewall.html#new-rules-are-not-applied
-
@johnpoz that was my initial thought too, that it might be something related to open states. But when I click on the Diagnostics -> States screen and filter states by this VLAN, I see no states which exist from the IP in question that I am using for testing the deny rule. I see some other states from other IPs from earlier usage, but not the one that I am testing.
Do I need to wait for ALL states on that VLAN to expire, like the original ALLOW rule won't go away until any states under it expire? I assumed it was only states for the IP in question which I am expected should be blocked but is being allowed.
-
@aaronssh You sure the device is on the new vlan? And not flowing through the other connection, etc..
You sure your actually doing vlans and not just different IPs on the same interface..
if I create a vlan on an interface. And I move client to new vlan interface. There is no way the old IP wold work at all, because its traffic would be on new vlan interface.
What specific traffic are you saying is being allowed, what what are you states.. You sure you don't have a floating rule bypassing your interface rules.
If traffic was allowed - then there has to be a state.. If your not seeing a state and your saying the traffic is working - then its not going through pfsense. Pfsense would have to create a state allow the traffic through the firewall.. If not then the traffic would not flow. Unless the firewall was not actually running.
I move devices between vlans all the time.. You would not ever need to reboot pfsense, you just have to be aware of your state table and validate your clients are actually in the vlan you think they are, etc..
-
@johnpoz
VLAN444 - 192.168.44.0/24 IP rangeI am pinging 192.168.44.44 from 192.168.9.14 on VLAN9 and all pings are going through, despite having a deny rule.
The states look like this:
And the firewall rules look like this:
Here the alias AdminPCs does NOT contain 192.168.9.14
Originally, before setting up these rules, there was an allow any/any rule. It seems like that rule is somehow still in effect?
-
@aaronssh said in reboot required to add VLAN?:
I am pinging 192.168.44.44 from 192.168.9.14 on VLAN9 and all pings are going through, despite having a deny rule.
if you don't want 192.168.9 to ping 192.168.44 then the rules would be on the interface 192.168.9 network is, not on the vlan444 - seems like a really odd vlan ID for a 192.168.9 network ;)
What interface are those rules on - because they make no sense that you would have source and destination both in the 192.168.44 network??
Rules are evaluated as traffic enters pfsense interface, from the network its attached too. Evaluated top down, first rule to trigger wins. No other rules are evaluated.
Those rules you show, 192.168.44 talking to 192.168.44 would have nothing to do with pfsense.. How would their ever be source of 192.168.44.44 unless those rules were on the 192.168.44 interface. So your rules make no sense.
If you don't want 192.168.9.56 to talk to 192.168.44.44 on port 443 - that would need to be a rule on your 192.168.9 interface.
If vlan444 interface is 192.168.44 how are you seeing traffic into the vlan444_admin interface from 192.168.9
This is not actually possible if your vlans are actually isolated.. There would be no way interface 192.168.44.x/24 to see traffic from 192.168.9.x inbound into it.. From that I would say you don't have your vlans isolated like you think you do...
-
@johnpoz The rules provided in the screenshot are on the VLAN444 (192.168.44.0/24) interface. VLAN444 is an admin VLAN which we want to isolate per the rules screenshot, so that only a few specific things can reach in to VLAN444.
"if you don't want 192.168.9 to ping 192.168.44 then the rules would be on the interface 192.168.9 network is, not on the vlan444'
I could be wrong but that is not how I understand it. We have 12 more VLANs besides just VLAN9 (192.168.9.0/24) and we don't want anything coming into VLAN444 (except for the rules in the screenshot), nor do we want any other VLAN cross-talk for the most part. The way you state it suggests we have to add a deny outgoing to VLAN444 rule on every VLAN interface other than VLAN444. That seems like an awful lot of work. Why not use a deny rule on VLAN444 so that nothing can come into the VLAN444 network? That is one rule rather than 12, and it wouldn't need updated every time we add another VLAN.
"Those rules you show, 192.168.44 talking to 192.168.44 would have nothing to do with pfsense.. How would their ever be source of 192.168.44.44 unless those rules were on the 192.168.44 interface. So your rules make no sense."
I don't see any rules that say anything about 192.168.44 talking to 192.168.44 Can you elaborate? My reading of the rules are:
- allow admin PCs (192.168.9.53-55) to talk to anything on 444
- allow anything on any VLAN to talk to 192.168.44.44 on UDP port 29810
- allow anything on any VLAN to talk to 192.168.44.44 on port TCP ports 29811-29814
- allow 192.168.44.44 to reach out to any VLAN or internet
- block anything else from reaching in to VLAN444
Is there an error in that interpretation of the rules?
-
@aaronssh said in reboot required to add VLAN?:
I could be wrong but that is not how I understand it.
you need to go back to the drawing board then - rules are evaluated as traffic enters an interface from the network its attached too..
https://docs.netgate.com/pfsense/en/latest/firewall/rule-methodology.html
In pfSense
software, rules on interface tabs are applied on a per-interface basis, always in the inbound direction on that interface. This means traffic initiated from the LAN is filtered using the LAN interface rules.I don't see any rules that say anything about 192.168.44 talking to 192.168.44
The rules you posted you show destination to 44.44 Is that pfsense IP? On this vlan - why would you not then use the vlan ADDRESS alias... You are then on the bottom blocking all access to vlan 444, on the 444 interface.. Which pfsense has zero control over, router has nothing to do with devices on the same network talking to each other.
As to a lot of vlans and not wanting to set all the rules on each interface - then using floating to create your rules where you can apply to multiple interfaces. But what you have posted you clearly need to readdress your understanding of how rules are applied... And I don't think you vlans are setup and working how you think they are since in if I have vlan 44 with IP 192.168.44/24 address - how would I have source traffic of 192.168.9 entering that interface? Unless this was a transit network? Which you make no mention of, and sure wouldn't use my admin vlan as a transit..
allow admin PCs (192.168.9.53-55) to talk to anything on 444
Those rules need to be on the 192.168.9 interface, not 444 interface.. Again rules are evaluated as traffic enters an interface..
Why would I want to filter traffic after the traffic has already entered the firewall and ready to leave, you wold block traffic you don't want to allow at the interface where it would enter the firewall. If you don't want vlan X to go to Y, then that rule would go on vlan X interface. If you want Y to be able to talk to Z but not X then those rules would go on Y..
Or you can put rules in the floating tab.. You can even do outbound direction rules on floating.. But for ease of reading and understanding of rules I woud highly recommend you take the time to put the rules on the specific interface. Will make traffic control way easier to manage going forward if rules are directly on interfaces vs having to figure out floating tab with a bunch of rules and different interfaces rules applied to and in what direction, etc. etc.. Now if you had 100 interfaces ok - but a hand full.. It doesn't take that long to create rules, especially basic like block access to the other rfc1918 networks.. Simple alias and simple rule placed on the interfaces..
-
@johnpoz said in reboot required to add VLAN?:
rules are evaluated as traffic enters an interface
What I am confused about is this: when traffic leaves VLAN9 (192.168.9.0/24) and enters VLAN444 (192.168.44.0/24), does that not count as traffic "entering the interface" of VLAN444? There is no other way for it to get there without exiting the VLAN9 interface and entering through the VLAN444 interface. Am I missing something?
If this DOES count as "entering" the VLAN444 interface, then why wouldn't my deny rules on the VLAN444 interface which are set to block all non-VLAN444 traffic, why wouldn't they block traffic coming from VLAN9?
If this DOES NOT count as entering the VLAN444 interface, can you explain how traffic is getting from VLAN9 to VLAN444? Doesn't it have to enter through the VLAN444 interface? What other route could it be taking if not through the VLAN444 interface?
-
@aaronssh said in reboot required to add VLAN?:
"entering the interface" of VLAN444?
No that is outbound on interface 444 into the 444 network.
-
@johnpoz said in reboot required to add VLAN?:
No that is outbound on interface 444 into the 444 network.
The terminology you are using is seemingly contradictory. I am not understanding how something can be outbound into. Isn't traffic either outbound (leaving the 444 network / 444 interface) or inbound (entering the 444 network / 444 interface)? How can it be leaving the 444 interface and entering the 444 network simultaneously? If it is leaving the 444 interface, doesn't that mean it is leaving the 444 network?
-
Maybe different words will help.
A packet enters the FW through an interface and exits the FW through an interface. Rules apply to entering.
Think of your house, you enter the front door if the key fits the lock. You can exit from the door of your choice because there are no locks on the inside of the house.
-
@aaronssh here does this help?
edit: The house analogy is good one..
If you don't want someone going into your back yard - do you let them into your house and then stop them at the back door entering the back yard. Or do you stop them from entering the front door in the first place.
Why would you want pfsense to process traffic if your not gong to let it leave anyway.. You stop it from "entering" the firewall in the first place.
-
@andyrh Ahhh, lightbulb moment! This clears things up. Thank you for that very helpful analogy!
-
@aaronssh It was confusing as hell to me too until someone explained in a way that my primitive brain could process. It's opposite how you intuitively want to think about it. I still get it backwards sometimes.
The house analogy is actually a fantastic way of keeping it straight in my head.
