Allow VLAN Traffic to Internet?
-
@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!).
-
@michaelcropper I like to think of it this way for where rules go..
You have a guy come to your front door (lan) and says he wants to go to the back yard (out your wan).. Do you decide to let him in, just to stop him at the back door and say you can not go there, after he has walked thru your house.
Or do you say sorry at the front door, you can't go there..
-
Thank you to everyone who contributed to this thread. You helped me get my VLAN working and appropriately secured and isolated.
