Allow VLAN Traffic to Internet?
-
@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.
-
@akuma1x Hmm, interesting. When I was just testing from one of the devices on VLAN 1, a "ping google.com" was failing, yet "ping 8.8.8.8" was working. Then I added that firewall rule and it seemed to solve it. I'll have another play with that to see if I can get it working without that additional rule if it shouldn't be required. I've nothing at all configured to override default DNS gubbins (i.e split DNS, internal DNS server etc.).
-
@steveits Yes that's right, took me quite some time to figure that one out. On one machine I had to turn the Ethernet connection from Public to Private (seems only possible via PowerShell, seems odd, buy hey, it's Windows so most things are odd) and that seemed to solve part of the problem. And on another machine I had to allow ICMP in Norton Firewall settings to allow pings to successfully run.
These kinds of things are like trying to find endless needles in hay stacks when it's not even clear what one should be looking for. Keeps things "interesting" (aka frustrating :-D )
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
"ping google.com" was failing, yet "ping 8.8.8.8" was working
The first requires a DNS lookup. If your device's DNS was set to pfSense that was not (yet) allowed.
The second is allowed by "IPV4 * to !RFC1918."@michaelcropper said in Allow VLAN Traffic to Internet?:
from Public to Private (seems only possible via PowerShell
There's a GUI way. On Wi-Fi open the network settings then drill into the Wi-Fi connection. I think it's the same on Ethernet but I'm on a Windows domain so that is detected first.
-
@michaelcropper while your free to use ! rules if you want.. After many a discussion on here about it.. I have joined the not to use ! rules camp, its better to be explicit in your blocks..
If you don't want thing got to rfc1918, then better to state that..
Here is example rules of a locked down vlan that can not go to rfc1918, your other vlans. But can can talk to required things on pfsense like ping and dns, ntp - but not other things like the gui.
In your rules, a user on the vlan would be able to access the pfsense gui on the wan IP (which is normally public)
There has been issues in the past with vips, and use of ! rules that could be confusing and allow what you might not. So better to be very explicit in your blocks.
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
What is the best way of doing this? Reading around seems that the primary recommended approach is to;
Here are my VLAN rules for my guest WiFi. It's configured to allow a guest to access the Internet and to ping the interface, nothing else. Adjust to taste.
