Allow VLAN Traffic to Internet?
-
What is the best way of doing this? Reading around seems that the primary recommended approach is to;
- Set an Allow All rule, then add a Block VLAN IPs / Private IP Ranges
This seems a bit backwards to me, perhaps I'm missing something.
Out of the box pfSense blocks all communication between all VLANs and to the internet anyhow, so seems odd to allow all, then block certain ones again as this is error prone i.e. if a new VLAN is added and the firewall configured to Allow All and Block VLAN IPs (but we forgot to add the new one), then this creates a security vulnerability. Likewise, if we actually want to allow talking between two of the VLANs, but not between some of the other VLANs, this seems a nightmare to manage.
In my simple brain, there must be an easy way for a setup such as;
WAN
LAN
VLAN 1
VLAN 2
VLAN 3To configure pfSense to say;
- VLAN 1 : Allow to internet
- VLAN 2 : Default, no rules, aka. block all
- VLAN 3 : Default, no rules, aka. block all
And to add, this is on a basic setup;
- Modem
-
- pfSense Hardware Firewall
-
-
- Managed Switch
-
Am I missing something blindingly obvious here? Seems there is so much configuration options in the guides, yet nothing for this extremely simply use case.
-
@michaelcropper
pfSense can block or allow certain IP protocols from certain source IP / ports to certain destination IP / ports.You want to allow a subnet access to the internet. In case of IPv4 internet IP range is 0.0.0.0/0.
Locally you will use private IP ranges (RFC 1918). However, these are part of 0.0.0.0/0. So how would you tell pfSense, what to do?An idea is to create an alias for RFC 1918 networks and add all respective network ranges to it. Then you can use this alias to block access to all your local subnets with a single rule or to allow it or any destination else, but this alias.
For example, my rule set for my IoT subnet looks like this:
At destination I used the RFC1918 alais with invert checked. That means, it allow access to any destination, but not RFC1918.
However, since this rule only allows outside access, an additional rule is needed if you run the DNS Resolver or Forwarder on pfSense.
I did this with a rule on an interface group including all internal interfaces:
Maybe this is what you're looking for.
-
@michaelcropper The rule order matters, so something like
VLAN1 interface:
allow TCP/UDP from VLAN1 Net to (VLAN1 IP) port 53 [allows DNS]
allow ICMP from VLAN1 Net to (VLAN1 IP) [optional]
block from VLAN1 Net to This Firewall
block from VLAN1 Net to LAN
block from VLAN1 Net to VLAN2 Net
block from VLAN1 Net to VLAN3 Net
allow from VLAN1 Net to anyTo handle the issue of adding VLANs later, one can create an alias like "RFC1918" and then use a rule like
allow from VLAN1 Net to !RFC1918
There are "Invert match" checkboxes when creating a rule. However per
https://docs.netgate.com/pfsense/en/latest/firewall/configure.html
"Using Invert Match on <interface> Net macros such as LAN net can lead to undesired rule behavior when the interface also uses Virtual IP addresses. This is due to traffic matching against the interface network OR the VIPs. For example, given a Subnet of 192.168.1.0/24, a VIP of 10.0.0.1/32, and a rule with a negated interface macro such as pass on $LAN from any to ! $LAN_net, traffic destined to 192.168.1.100 will pass because the destination IP address does not match the VIP." -
Am I correct in my understanding that the VLAN X Firewall Rules are acting as both Inbound Rules AND Outbound Rules at the same time, depending on how the specific rule is configured (i.e. Source/Destination)?
The UI/UX isn't very clear in pfSense, particularly when compared with things such as AWS which clearly states which is an inbound rule and which is an outbound rule etc.
So, what I'm understanding here is that as a general rule of thumb what would be configured for a new VLAN X;
Outbound Rule
Allow All
From VLAN X
To 'invert match' {private IP ranges} (aka. to allow the VLAN access to everything except private IP ranges, aka. the internet)Inbound Rule
Nothing to configure as this is blocked by default?
What about on VLAN 2
I've noticed situations whereby when an allow all to allow all is configured on VLAN 1, then this seems to be able to access VLAN 2 all ok. Is that because a single allow all to allow all rule is both acting as an inbound AND outbound firewall rule at the same time?A lot of the guides / conversations online always talk about an allow all to all, which seems to be causing a lot of confusion for me.
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
Firewall Rules are acting as both Inbound Rules AND Outbound Rules at the same time
No, firewall rules are for inbound traffic on an interface. So generally from "that Net" to "destination" however there are specific times when it's not that network such as another network routed out through pfSense.
Floating rules are (much) more complex and can handle outbound. I'd suggest avoiding those until you're more familiar with pfSense.
Allow from source Net to any/all will allow traffic anywhere else including other local networks and to pfSense itself, hence my rule order above, with the allow rule last.
-
@SteveITS This is where the pfSense terminology really confuses me.
"firewall rules are for inbound traffic on an interface"
I don't doubt what you're saying is correct. This in practice is what confuses me, if you could help me understand that would be much appreciated.
i.e.
"So generally from "that Net" to "destination"" (I'm assuming to follow the thread aka 'VLAN 1' to 'the internet')
In my brain, that would be considered an Outbound Rule
And when testing various combinations in pfSense, it would seem that a rule needs to be configured on the VLAN X Interface from where the traffic is coming from to match the rule.
Makes me wonder "What is an Interface" in pfSense terminology. It doesn't seem to make much sense in my brain. Hence why the thought was that it was acting as both as an Inbound and Outbound configuration set.
Likewise in the first example you gave with these items;
block from VLAN1 Net to This Firewall
block from VLAN1 Net to LAN
block from VLAN1 Net to VLAN2 Net
block from VLAN1 Net to VLAN3 Net
allow from VLAN1 Net to anyThat would suggest that the firewall rule is configured to block the outbound rule from VLAN 1.
What I'm pondering in my head is that if I've got say 10, or 100, or 1000 VLANs, is that I don't want to have to configure the exponential growth of blocking outbound rules across every VLAN as things grow across each combination/permutation of the rules.
I'm sure I'm just missing some silly understanding in my head to understand how this works. It just seems a bit odd looking at this from a cloud native mindset. I must be missing something here.
My understanding from things like AWS.
- Default Outbound Rule: Allow all
- Default Inbound Rule: Deny All, except Port 22 for SSH Access
I know things aren't quite like for like, but there has to be some similarity. Perhaps I'm missing something obvious.
-
This is the rule I use to allow Alexa to the internet, but not to any of the other VLANs. Notice the 'Not' in the description and rule.
Excluding floating rules, the best way I have found to think about rules...
When you get to your front door, if you have the key you can enter. Once inside you may exit any door you desire. pfSense is the same way, the rule (key in the example) is only evaluated when you enter a door, but not when you exit a door.I hope this helps.
-
@michaelcropper Think of each port having an ingress and an egress,
Why would you block the egress side? If something was let into the ingress side it would be allowed to the egress using common sense. Why would something that was allowed in be blocked from leaving?
So the rules apply to the ingress of each interface.
If it's allowed in, in can definitely be allowed out.
If it wasn't allowed in, how can it be allowed out? -
This is a good example actually @AndyRH as this illustrates my thought process.
The rule you have in the screenshot which is applied to VLAN 1 (in the original example, aka. VLAN 66 in your screenshot) is a rule that in my brain says..... "Allow traffic from within VLAN 1 to go to anywhere it likes, except from the 3x private network address ranges". To me, I'd classify that as an Outbound Rule, as it is the sending party that is determining where the traffic is allowed to be sent.
Let's expand this example, let's say this rule was configured as "Allow traffic from within VLAN 1 to go anywhere it likes" (basic allow all - allow all rule). How would say VLAN 2 say, no, I don't want traffic from VLAN 1, in fact, I don't want traffic from anywhere. I'll allow traffic from VLAN 3 though. In my brain, this is like the bouncer on the door of a bar.... sorry mate, you're not coming in. I don't care if the Queen of England has sent you here, I don't like the cut of your jib.
Where as it's almost like pfSense works in the sense that it's the taxi driver who drops you off at your destination tells you if you are allowed in the bar or not.
I think ultimately I'm going to get that !RFC1918 rule set up to get this working properly. I'm still just trying to understand the logic in my head for why pfSense works in this way. Logically it makes no sense to me as it's completely the opposite of what I would expect to see.
-
@michaelcropper It's from the perspective of the network interface. The packet goes from your PC to the router and arrives on LAN. So it is an inbound packet the LAN interface sees arriving. pfSense verifies it is allowed, and if so figures out where to route it.
PC -> LAN -> (pfSense) -> WAN -> web site
or
Internet -> WAN -> (pfSense) -> LAN -> web serverPut another way, from your POV/interpretation if you had 100 VLANs, in order to prevent VLAN 2 from accessing 3-99 you'd still have to set up a rule on those 97 interfaces denying VLAN 2.
Floating rules can handle outbound but are more complex to understand and get right, particularly match vs quick.
-
Ok, I think I'm starting to understand.
It's essentially a case of, once you're (aka. the network packet) is through the front door you're given the permissions to go to certain places.
I was thinking about this previously more a case of once you're through the front door you can go where you like as you choose, but it's not quite like that.
If I've understood this correctly, I think this diagram I've just thrown together explains how it works well?
Have I got that correct? So basically once you're (aka. the network packets) are past the perimeter pfSense Firewall, then they are good to flow where they are allowed to.
Rather than say how the likes of something like AWS Security Groups work where you attach a security group to a resource which has inbound and outbound rules which are related to the VM. i.e. VM, outbound allow all, inbound allow only port 22 etc. I guess things like AWS Security Groups give that next level of fine grained control as it's the next (and next and next) layers of virtualisation further down/up the stack etc.
-
@michaelcropper Yeah, that's essentially a correct diagram. I'm nit-picking, but you did forget the line connecting the LAN network out to the internet (WAN) with the LAN default to any rule, and there should be lines from LAN to all of the VLANs, since again, by default the LAN is allowed to any destination.
If you don't like any of that behavior, you have to set specific block rules on the LAN interface, and possibly other additional interfaces that you create.
-
@akuma1x Good call, it's good to point these things out as it's often these small details that catch a lot of people out in their understanding. Often an accurate diagram can help someone understand 1000x faster and more accurately than endless discussions backwards/forwards.
So if I've understood you correctly, this is a more accurate diagram;
-
One thing I've also just noticed now I've got the !RFC1918 Alias configured. Seems that it's also important to configure a DNS Port 53 Allow All rule for "The Internet" to work properly.
Are there any other nuances that need to be configured?
So essentially to allow a VLAN access to "The Internet" to do anything/everything it may want to do with any host/domain/port etc. We need to configure;
And
Seems relatively straight forward now I've worked through this discussion with everyone.
Anything I've missed?
-
@michaelcropper Yeah, that new diagram is better. You moved the VLAN1 green line to the LAN interface, and that's not correct. Because, you've got a firewall rult on VLAN1 that says allow NOT to RFC1918 addresses, of which the LAN is a part of. You should move that green line on VLAN1 back to the WAN interface, that was the correct path.
Also, nit-picking again, you probably shouldn't specifically call out "inbound" or "outbound" directions just yet. Those terms are in fact used, but on floating firewall rules. But, you're not there yet. You first have to get the concept of interface firewall rules understood before you can even start trying to figure out floating firewall rules. If you want to use "inbound" or "outbound" terms just for yourself, that's fine. But, here on the forum, when those are said, floating rules will be assumed, I'm thinking.
The orange arrows you added are good. Keep in mind, lots of host computers attached to the different networks will BLOCK traffic from other networks. This is a security feature built into many operating systems. If you are struggling to communicate between internal networks (LAN, VLANx, VLANy, VLANz, etc.), you have to remember to check the firewall software on the host machines. This comes up a lot here on why stuff isn't working between different internal networks. This usually does not apply to host machines on the SAME network.
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
once you're through the front door you can go where you like as you choose, but it's not quite like that
pfSense allows the packet (or blocks it), but then forwards it where it is supposed to go. The packet would need to change in transit to get somewhere else. (i.e. NAT)
@michaelcropper DNS rule destination can be "This Firewall" or that VLAN's IP address of the router if you're using pfSense for DNS. Otherwise the allow-to-Internet will allow public DNS anyway. As I noted above ICMP to pfSense may be desired, for troubleshooting.
-
@akuma1x Thanks, good spot. For completeness and future readers (likely me :-D ) updated diagram with correct terminology and lines;
And yes, I have noticed that when having a play. Windows machines blocking basic ping commands, what's all that about. I'm not going to publicly admit how much of my life I have wasted over the last couple of weeks trying to debug a non-issue which was ultimately caused by the OS and/or software such as Norton blocking basic pings :-D Coming from a web application development background, I've never seen any Linux machine blocking basic pings out of the box. All a learning curve though.
In "Cloud Native" worlds, everything is classed as an Inbound Firewall Rule and an Outbound Firewall Rule. Interesting the terminology means something completely different when getting down to the physical network hardware like pfSense.
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
One thing I've also just noticed now I've got the !RFC1918 Alias configured. Seems that it's also important to configure a DNS Port 53 Allow All rule for "The Internet" to work properly.
If you are using an outside DNS service (google, opendns, quad9, etc.) and you set the server values in the DHCP server for that particular interface, then you do not have to add a DNS rule in your list of firewall rules. Simply put, an outside DNS server is not in an rfc1918 address space, so your single firewall rule that you already have allowing everything to NOT rfc1918, should suffice.
-
@steveits Thanks. So like this?
Re. the ICMP (aka. "ping"), is there another rule you'd recommend adding?
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
And yes, I have noticed that when having a play. Windows machines blocking basic ping commands, what's all that about.
Check if the network is marked public or private. On first connection Windows asks about “should this Pc be discoverable” or something like that. Yes=private. No/no answer=public, e.g. coffee shop Wi-Fi. Firewall blocks more on private.
