Best practice for controlling VLAN traffic?
-
I'm trying to learn about how VLANs work and, while I've so far been able to do everything I want to do, one thing that confuses me a bit is how traffic rules are set up. The guides I've read online seem to always set it up so that a VLAN is able to access everything, then individually block whatever that VLAN shouldn't access. On my test setup, I've got VLAN10, VLAN20, and VLAN30. So if I wanted VLAN10 to be able to access VLAN20, but not VLAN30, I would set up an allow-to-any rule on VLAN10, then also set up a block-to-VLAN30 rule. Meaning, it would also automatically have access to any other interfaces added later. This seems, to my non-network engineer brain, kind of backwards, I would think it should be blocked by default and you would manually add access to new interfaces if it needs it.
So I figured I'd try doing just that, adding only an allow-to-VLAN20 rule on VLAN10, and it seemed to work just fine. So now I have two questions:- Why is the convention to allow all then selectively block, rather than block all and selectively allow? (or am I totally wrong and this is not how it's normally done?)
- I tried allowing internet connection to VLAN10 this way, by adding an allow-to-WAN rule on VLAN10, but it doesn't seem to have worked, I can't ping 8.8.8.8. By adding an allow-to-any rule on VLAN10, I'm able to ping 8.8.8.8. So why does an allow-to-VLAN20 rule allow me access to the VLAN20 network, but an allow-to-WAN rule not allow me access to the internet? Is the only way to allow internet access, but block VLAN30 access, to use an allow-to-any rule and a block-to-VLAN30 rule? This seems to be the case, but also seems really strange to me, so I figured I'd ask.
-
@jblackburn said in Best practice for controlling VLAN traffic?:
Why is the convention to allow all then selectively block, rather than block all and selectively allow? (or am I totally wrong and this is not how it's normally done?)
pfSense blocks anything by default on interfaces except on the LAN.
I tried allowing internet connection to VLAN10 this way, by adding an allow-to-WAN rule on VLAN10, but it doesn't seem to have worked, I can't ping 8.8.8.8. By adding an allow-to-any rule on VLAN10, I'm able to ping 8.8.8.8. So why does an allow-to-VLAN20 rule allow me access to the VLAN20 network, but an allow-to-WAN rule not allow me access to the internet?
WAN is just an interface, not the internet. "WAN net" is the subnet assigned to the WAN interface, not the internet.
Suggestion for handle public / private access:
Create an alias, call it RFC1918 and add all RFC 1918 networks to it.The to allow internet access add a pass rule to the concerned interface and set this alias as destination with "invert match" checked. So this rule passes access to any destination, but private networks.
If you want to use the same rule on multiple interfaces you can create an interface group and add to rule there.
This rule is still safe, when you add further subnets (assuming you use private ones only).For allowing access to other local subnet, you can add additional rules then to the respective interfaces.
However, consider that the rule I mentioned above does not allow any internal access, even not to pfSense itself, e.g. for DNS.
-
@viragomann said in Best practice for controlling VLAN traffic?:
pfSense blocks anything by default on interfaces except on the LAN.
Sorry I worded that poorly, by "allow all then selectively block" I meant when going from the default state of nothing is allowed, the first step is to allow all, then you go in a block selectively.
WAN is just an interface, not the internet. "WAN net" is the subnet assigned to the WAN interface, not the internet.
So if my pfSense's WAN IP address is say 87.44.152.38, then the WAN net would be the 87.44.152.0 subnet? What would even be on that subnet? Other firewalls?
Suggestion for handle public / private access:
Create an alias, call it RFC1918 and add all RFC 1918 networks to it.The to allow internet access add a pass rule to the concerned interface and set this alias as destination with "invert match" checked. So this rule passes access to any destination, but private networks.
If you want to use the same rule on multiple interfaces you can create an interface group and add to rule there.
This rule is still safe, when you add further subnets (assuming you use private ones only).For allowing access to other local subnet, you can add additional rules then to the respective interfaces.
That makes sense, I will play around with that a bit.
However, consider that the rule I mentioned above does not allow any internal access, even not to pfSense itself, e.g. for DNS.
But I could add a rule on top of this to allow for internal access right? Like if I wanted access to the internet, pfSense, and anything on VLAN20, I could have the top rule be allow-to-pfSense, then allow-to-VLAN20, then the inverted RFC1918 rule. Am I understanding that correctly?
-
@jblackburn said in Best practice for controlling VLAN traffic?:
when going from the default state of nothing is allowed, the first step is to allow all, then you go in a block selectively.
The rules are processed in order. The allow rule has to be last.
@jblackburn said in Best practice for controlling VLAN traffic?:
then the WAN net would be the 87.44.152.0 subnet? What would even be on that subnet?
Usually, other ISP customers and your gateway. For not-edge routers, could be other internal networks.
Similar thread: https://forum.netgate.com/topic/178105/request-for-examples-of-working-guest-network-rules
-
@jblackburn said in Best practice for controlling VLAN traffic?:
But I could add a rule on top of this to allow for internal access right? Like if I wanted access to the internet, pfSense, and anything on VLAN20, I could have the top rule be allow-to-pfSense, then allow-to-VLAN20, then the inverted RFC1918 rule. Am I understanding that correctly?
Yes. As mentioned, rules are processed from the top to the bottom of a ruleset, rules on interface group are probed before ones on member interface and floating rules are probed at first of all.
If a rule matches to a traffic (interface, address family, protocol, source IP and port, destination IP and port) it is applied and followings are ignored.However, since the rule I suggested above matches to non-private destinations only, you can also add rules for internal destinations below of it.
-
This post is deleted! -
@viragomann Got it, thank you very much for your help.