Allow VLAN Traffic to Internet?
-
@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.
-
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
