Guest VLAN isolated from Management LAN: rules to keep Internet access?

Chti · Jan 13, 2018, 11:14 PM

Hi there

On my PfSense box I have my LAN and several VLANs.

My LAN has currently only all switches and access points on it (so it's my management LAN). I moved all my other devices to different VLANs.
Some VLANs have rules not be to able to access the other VLANs, but all can currently access my LAN

If I want to prevent some VLANs (e.g. Guest VLAN) from being able to access all the management devices on my LAN while keeping Internet access, what rules would be required to achieve that?

Currently, if I block LAN access, I have no Internet access.

Many thanks for any help! :D

johnpoz · Jan 14, 2018, 1:15 AM

Please post up your rules so we can discuss what your doing wrong.

Rules are evaluated top down, first rule to trigger wins.. No other rules are evaluated.

If you want to block access to lan, then block that before access to any any (internet)… It really is that simple.. Walk down your rules as you picture the traffic you want to allow or block.

Chti · Jan 14, 2018, 5:39 PM

Ok
Actually I solved some other issues I had, which slightly changes the info I gave further up: so even though I block LAN I DO get Internet access

So below is an example of what my rules for one VLAN look like. In this case the VLAN has the ID 99 and I don't want this VLAN to be able to access in any way any other VLAN or LAN:

My current rules are (see screenshot):

blocking Interface 99 from reaching all the other Interfaces (LAN+VLANs)
Any DNS query is redirected to the DNS_OpenDNS alias (list of Its for Open DNS servers), so that all queries on this interface use some filtered DNS

However when using Diagnostic/Ping, I can still ping a device on another VLAN, which I assume is because it travels up to the PfSense box then down to that other VLAN again?
Wouldn't that mean the other VLANs are still accessible in some way as well?

Sorry, I am still a networking beginner, but any insight would be appreciated

GoldFish · Jan 14, 2018, 9:33 PM

@Chti:

However when using Diagnostic/Ping, I can still ping a device on another VLAN, which I assume is because it travels up to the PfSense box then down to that other VLAN again?
Wouldn't that mean the other VLANs are still accessible in some way as well?

Diagnostic/Ping is from the firewall itself so nothing is travelling up to the pfSense box. It is from pfSense directly. The source will be pfSense when you use Diagnostic/Ping. You are still able to ping because pfSense has access to all. This does not mean a vLAN has access to other vLAN

Usually i start with Any Any rule and once i confirm that its working, I would put the block rules on top of Any Any which is what you have done. The best way to test the blocks is to actually use ping or tracert or try to communicate from one vLAN to another and not from pfSense.

johnpoz · Jan 15, 2018, 8:08 PM

So you don't want this vlan 99 to access any of your other networks? Which I assume are all rfc1918 space.. Do want this vlan to be able to access anything on pfsense at all?

You rules could be done in 2 rules - Derelict doesn't like to do it this way… ;) But it is another way to skin the cat...

So leave your redirect rule there.. But vs doing an any any rule, you can get rid of all of those block rules and change your any any rule to a ! (not) rfc1918 rule..

Create an alias, put in 10/8, 192.168/16, 172.16/12 this makes up the rfrc1918 space which all your other vlans are on.. Then on your any any rule just make it ! rfc1918 alias.. So if dest is anything rfc1918 from this vlan it would not be allowed and blocked by the default rule. If ie a public IP address then it would be allowed..

Derelict · Jan 15, 2018, 9:15 PM

Reject to dest rfc1918 then pass any. :)

johnpoz · Jan 15, 2018, 9:17 PM

Yup that works too - see lots of ways to skin the cat ;)

Derelict · Jan 15, 2018, 9:19 PM

Only one right way though. :)

johnpoz · Jan 16, 2018, 9:59 AM

heheheeh - ROFL…. The Derelict way ;) heheheeh

What if combine your reject to rfc above my ! rfc allow rule? Would that be ok? ;)

Velcro · Jan 18, 2018, 6:51 PM

Not trying to stir the pot but thanks Johnpoz and Derelict for the options but what is the real difference?

is the thinking that "! RFC1918" is potentially "leakable"? Is there a way to quantify the difference? When would one use the "!"?

johnpoz · Jan 18, 2018, 7:09 PM

I think awhile back there was some sort of issue with the not rules.. But as always you should always validate any sort of rules you put in place are actually working the way you believe they should work, etc.

Derelict method of actual bock makes the rules more clear cut and obvious to yes no function. I believe he is of the mind set you do not block with an allow statement - but I do not see it that way. Not blocking anything with that rule, the default block is what blocks. I am just being more restrictive on my allow.

We have over the years gone round a few times on this - we agree to disagree if you will ;) I do see his point clear blocks in your rules, and am a fan of that.. I don't see anything wrong with doing it that way. But I am also a fan of min amount of rules to accomplish the goal..

Derelict please chime in on your take on it.. It has been a while since we have discussed this ;) heheheh

I don't see it right/wrong way, just a different way to skin the same cat is all. If you had a bunch of networks to block your rules list could get quite long… Sure you could put your networks into a alias.. You really need to understand the specifics of setup, ie the breed of the cat if you will to know which way to skin might be the best option.

If your a fan or watch silicon valley... Its like tabs vs spaces ;)

Derelict · Jan 18, 2018, 7:24 PM

If you want to block traffic, block it. Don't rely on pass rules to block traffic. Particularly pass ! rules.

https://redmine.pfsense.org/issues/6799

johnpoz · Jan 18, 2018, 7:33 PM

See that where are difference is… That rule is not blocking anything.. Its just a specific allow vs any.. The block is default block.. Your against specific allow rules? ;)

Agree to disagree as said ;)

That redmine entry should never happen to be honest, because that sort of setup is just full blown borked of running multiple layer 3 on the same layer 2.... As I stated you should always validate your rules are working as expected..

So you see no use for the ! at all in a destination? Or source - you don't think it should be an option at all?

Derelict · Jan 18, 2018, 7:35 PM

The default pfBlocker DNSBL config creates that scenario.

I am not against specific pass rules to pass traffic that is to be passed allowing fall-through to the default deny.

I am against using a pass rule to ! something expecting it to function as a block rule for something.

If you want to block it, block it with a block rule.

johnpoz · Jan 18, 2018, 7:36 PM

Which is borked ;) If he wants to listen on a address - then create a vip in the network.. Not some 10.10.10 address or whatever it uses out of the box..

Derelict · Jan 18, 2018, 7:38 PM

I agree. That vip should be on localhost.