Allow VLAN Traffic to Internet?
-
@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.
-
I've been doing some more testing, and I'm confused again.
Scenario 1 - Allow all !RFC1918
I created an alias and configured the three IP ranges;
- 10.0.0.0/8
- 172.16.0.0/12
- 192.168.0.0/16
I then configure VLAN 1 to: Allow All from Any to ! RFC1918 Alias, and, to Allow Port 53 from Any to This Firewall.
Great. This worked.
So I thought I'd try something a little different to see how this behaves. Given the previous comment around the other camp to explicitly block rather than a blanket block etc.
Scenario 2 - Block All VLAN Traffic
So I configured another alias for all the VLANs;
- 192.168.2.0/24
- 192.168.3.0/24
- 192.168.4.0/24
- etc.
And I configured the firewall rule on VLAN 1 to: Block All to VLAN Traffic Alias.
And it didn't work.
Then I tweaked that rule to: Allow All to ! VLAN Traffic Alias
And it worked.
I don't get it. Aren't those two rules exactly the same thing?
What I am not understanding?
-
@michaelcropper said in Allow VLAN Traffic to Internet?:
So I configured another alias for all the VLANs;
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24
etc.And I configured the firewall rule on VLAN 1 to: Block All to VLAN Traffic Alias.
And it didn't work.What exactly did not work?
Consider that adding a block rule doesn't break already existing connections. If pfSense has a state for connection, the traffic is still passed.
To drop the existing connections you have to kill the states. Diagnostic > states -
@viragomann Should have added, I use the Reset States feature after all rule configuration changes to make sure they flush through.
-
@michaelcropper and in what order did you put the rules.. Order matters!
Top down, first rule to trigger wins, no other rules are evaluated.
-
@johnpoz It was the only rule at the time, I'm pretty sure.
-
@michaelcropper well then your states did flush, or your rule was wrong - its that simple. Maybe your rule was tcp only and you were doing icmp?
Here so got a constant ping going.. Added the rule - and still pinging
Notice that rule doesn't show any hits the 0/0
I then kill the state.. Ping stops
And you notice on the firewall rule - its showing hits on the rule the 0/300 now..
-
S SteveITS referenced this topic on
-
S SteveITS referenced this topic on
-
I think I've found a combo that works, and I also think I know why it works now too.
Essentially the firewall rules work kind of like a coin sorting machine. In the sense that once the network packet has been "captured" by a rule, then that network packet has been captured and sent where it needs to go, so it can't be double evaluated by a second or third rule.
To put it simply in a more visual way, essentially something like this - i.e. a coin / bit of network traffic can't fall through two slits, only the first one that matches;
Hence why the top screenshot in this reply this seems to be working now when I am testing from PC 2, on VLAN 2, this can't ping PC 1 on LAN, it can't ping Printer on VLAN 3, and can't ping server on VLAN 4. Because in each of these scenarios it is being captured by the second rule for "Block All VLANS and LAN" traffic.
And it allows ping google.com from PC 2 on VLAN 2 because that is getting caught by Rule 1 to allow Port 53 to This Firewall to access the cached DNS stored on the firewall based on whatever the authoritative DNS server is for any domain I ping on the internet.
And hence allows everything else to work when accessing the internet because of the last rule, which is required because there is a 4th hidden rule which is to block everything, so if we didn't have this rule then very little would work.
Have I understood that correctly? It feels like it's starting to sink in.
-
@michaelcropper If you want to think of it as coin sorting machine sure ok ;)
Top down, first rule to trigger wins, no other rules are evaluated..
-
@johnpoz Thanks. It's making sense now.
I think where I have been getting confused for a while is that I was getting mixed up about how the pieces connect together. i.e. I was thinking that because I am sending a ping from PC 2 on VLAN 2 that it is already inside the firewall because of how the VLANS are configured, but that isn't the case. It's more a case that everything is distrusted until the final hop actually into the pfSense firewall, then the packet is captured by one and only one of the rules, which states where it is allowed to go, then if the network packet is asking to go somewhere it is allowed, then on it goes, whereas if it is asking to go somewhere it is not allowed, then it's blocked by that firewall rule and doesn't go any further (or responds with a 'computer says no' type message).
Networking concepts are extremely abstract and most documentation online conflates terminology and doesn't make it clear between the physical and virtual layers which makes things even more confusing.
The few analogies I've used along the way have certainly helped to solidify my understanding now so thanks for the help and patience answering the questions (same to all in this thread!).
