How to arrange my LAN?
-
disclaimer: I'm not sure if this would go into the firewall section, the routing section, or the "clueless netadmin" section. (Is there one of those?)
This is kind of a "How should I organize my LAN" type question… I have my own ideas (which I'll mention), but first I'll back out and explain the overall layout and goal (in case people have helpful suggestions on how to better organize things.)
I'm an "advanced home" user. I have an Active Directory server, and members of my family all have AD accounts. (No, it's not really needed, but once it was set up, it made doing some other things easier.) I have two NAS devices, both of which are attached to the active directory. I also have a few other server type machines that are secured via ADS. I also have machines I'd rather not have exposed outside of ADS authenticated people.
Then, I have a bunch of appliances. Some exist on the LAN only so they have internet access (such as my nest thermostat) and some actually do some interaction with other LAN devices (such as my TiVo DVR's.)
Of course, I have user computers. Mine, the kids, my wife, etc. ALL of these are on the ADS. If they aren't physically wired into the LAN, they use EAP/PEAP to authenticate to RADIUS via the ADS. (I use domain policies to force any wifi only Windows machines to log on wifi via EAP even before a user logs on...RADIUS can authenticate a machine as well as a user.)
Other (non-windows) devices might also log on wifi via EAP. For example, android devices and iThings.
There are also wifi guests. If my kids have friends over, we have a party or whatever - I have a guest wifi that uses WPA2AES PSK.
Finally, there are what I can only call "management interfaces." They include the management ports for my switch (vlan1), the IPMI interface on my pfsense box, the method to access my AP's management tools, etc.
My AP is current a single UniFi AP-AP-Pro flying saucer. That will probably grow to two fairly soon.
My primary switch is a netgear GS724Tv4 ("smart managed" L2 switch) and a secondary 16 port ("smart, but not managed") switch that does VLANs, but not much else. (It also does static LAG, but not LACP.)
pfSense, my switches, the NAS devices, and the ADS all use 2x gigabit ethernet (LACP or static LAG.)
....
My goal is that there are several different groups of machines/people. There are the "system" interfaces (ADS, NAS, etc), management interfaces (switch, AP, etc), trusted humans (anyone authenticed to ADS and most things physically plugged into the LAN, untrusted guests (anyone using the guest wifi) and things I want isolated (they just need internet access.)
Here's where it gets difficult:
Any "trusted human" needs access to any "system."
Any "untrusted guest" needs to be able to "talk" to "trusted human" machines, but NOT to "system" machines. (in fact, they should be on the same subnet. My kids are serious minecraft fans, and minecraft clients find each other with network broadcasts.)
The management stuff can be completely isolated on a vlan (and I can just use a virtual machine to acess them.)
I'd like for some of the appliances to be able to talk to some of the system devices, but I don't NEED that. (This is to allow the tivo machines to "talk" to the NAS machines.. as my NAS appliances can backup recorded shows and then they can be played back across the network.)
....
My idea on how to accomplish most of this...
vlanManagement: this would be vlan1. All the proper machines would either tag themselves for vlan1, or be untagged on vlan1. Not much else to say here...
vlanIsolated: this is for devices that exist only to see the internet. There's a special SSID on the AP for these, and it can set a vlan.. perhaps "99", and subnet 192.168.99.0
vlanSystem: This would be for the servers, etc. I'll call this "vlan4" and it'll be it's own subnet (192.168.4.0)
vlanNormal: This is for trusted users. I can use "vlan5" for it. The AP would push the EAP validated SSID to this vlan, and most ports on my switch would be untagged for this vlan. There would be nothing blocking any routing between vlanSystem and vlanNormal
vlanGuest: This is for untrusted wifi guests. I can use vlan6 for this and the AP will take care of making sure the proper vlan tag is set...
Finally, set up a bridge (br0?) in pfSense that bridges vlanSystem and vlanNormal. This is where I'm not sure what I'm talking about. ;) I think, based on what I've read, I can create a bridge between vlanSystem and vlanNormal, and they'd end up being on the same interface (and subnet), but firewall rules are applied to the source interfaces (vlanSystem/vlanNormal) before any packets can cross the bridge. If so, I'd create rules in the firewall DENYing traffic between vlanGuest and vlanSystem. This would be... 192.168.200.0
One thing I'm kind of lost on is how the "bridge" interface would interact with 802.1q on the switch. Would I have to add the bridge to yet another vlan?
....
This seems complicated to me. Of course, my requirements aren't simple either. However, if there's a better way, I'd love to hear (read) it. Comments or suggestions?
Thank you
Gary -
Why do you want a bridge??? There is no reason to bridge unless yes you want to do broadcasting for some reason and still want to be able to control access between devices on each side of the bridge.
Normally you would just allow the traffic you want, there really is no point to "bridge" Other reason to bridge would be to cross media times and the devices need to be on the same layer 2 network for whatever reason? Like wifi to wired with broadcasting working, etc.
I really don't see why you would need a bridge. If you need to do service discover stuff across layer 3 you could use something like ahavi or igmp proxy, etc. The use and need of a bridge going to be rare.. Isolation of devices is always better and easier when they are on their own layer 2 and force them to cross your router/firewall for control. I would really steer clear of setting up a bride unless there is no other way to accomplish what your looking to accomplish.
What traffic will need happen between the devices/users on the these 2 vlans??
-
Why do you want a bridge??? There is no reason to bridge unless yes you want to do broadcasting for some reason and still want to be able to control access between devices on each side of the bridge.
Normally you would just allow the traffic you want, there really is no point to "bridge" Other reason to bridge would be to cross media times and the devices need to be on the same layer 2 network for whatever reason? Like wifi to wired with broadcasting working, etc.
I really don't see why you would need a bridge. If you need to do service discover stuff across layer 3 you could use something like ahavi or igmp proxy, etc. The use and need of a bridge going to be rare.. Isolation of devices is always better and easier when they are on their own layer 2 and force them to cross your router/firewall for control. I would really steer clear of setting up a bride unless there is no other way to accomplish what your looking to accomplish.
What traffic will need happen between the devices/users on the these 2 vlans??
The bridge would be to accommodate this part:
Any "untrusted guest" needs to be able to "talk" to "trusted human" machines, but NOT to "system" machines. (in fact, they should be on the same subnet. My kids are serious minecraft fans, and minecraft clients find each other with network broadcasts.)
Most "consumer" level broadcasting doesn't seem to support IGMP. They just.. well.. shout: "HEY! ANYONE ON THIS SUBNET WANNA PLAY MINECRAFT?" to "networkaddress:port" I've also been unsuccessful using mDNS (avahi) with some broadcasting.
…but they'd originate on separate vlans so that I'd have a way to block untrusted machines from talking to the system machines.
Is there a better way to accomplish this? That's why I posted the question and asked for comments and suggestions. :)
-
Why do you want a bridge???
Was my answer insufficient? I've been waiting with baited breath for your "Hero" knowledge and wisdom to offer some advice… being that you decided to respond to the thread to begin with.
That IS why you responded, right? To help? (Some might suggest that you only responded to troll, but surely that isn't the case.)
Have you decided that my idea of using a bridge is, after all, the most brilliant thing that you've ever read? I kind of doubt it... being I was basically shooting from the hip with my idea - lacking in all the wonderful knowledge and experience that someone like yourself must possess. However, it was the best idea I could come up with at the time, and it does communicate the goal I'm trying to achieve.
Sarcasm aside... Did you intend to do more in this thread than just troll the bridge idea? You basically ripped me for even thinking it, but offered no alternative, and no reason WHY using the bridge is such a bad idea given my requirements. (Oddly, you did say when it SHOULD be used - which seems to include my use case.)
I really did start this thread asking for help, advice and suggestions - fully realizing that my initial idea might not be optimal.
Gary
-
"after all, the most brilliant thing that you've ever read? "
Yeah no… Sorry I have not gotten back to this thread since you responded n the 1st and its now the morning of the 3rd.. Unlike you I was not waiting with bated breath on what sort of nonsense you would come up with on why you thought you needed a bridge.
Sorry but you have yet to give one reason why other then you believe they need to be on the same broadcast domain. Minecraft sure and the F does not need to be on the same L2 to play against each other..
As to consumer broadcasts not supporting igmp??? WHAT??
How about you give an exact example of what is not working across subnets and we can figure out what your doing wrong..
-
How about you give an exact example of what is not working across subnets and we can figure out what your doing wrong..
I did give an example. Apparently you don't believe me? Start minecraft on an android device on one vlan - allow it to start the server aspect. Start minecraft on another handheld on a second vlan (that has a route to the first) and select the option to join another game.
If the handhelds are on the same subnet, the game running on the first device would show up on the second. If they aren't on the same subnet, the only way to join would be to figure out an IP address.
-
"the only way to join would be to figure out an IP address"
You don't say… Well no shit they are not on the same layer 2.. If you want these devices to play together and do broadcast to find each other then why not just freaking put them on the same layer 2.. WTF does that have to do with bridging?
Or if your server is on wire and your on wifi - then yeah put in the freaking address..
-
WTF does that have to do with bridging?
You really don't bother to read what you reply to, do you?
-
I'm not a Minecraft/gamer aficianado by any means, but I would have thought you could simply provide a FQDN (eg. "thisisthegame.here.now") that would reference through DNS setup on pfSense to get you across the VLANS.
As I said I don't know all the ins and outs of the Gaming world, but getting away from from the "it should just work" model, may save you from some grief.
Just my $.02
-
I'm not a Minecraft/gamer aficianado by any means, but I would have thought you could simply provide a FQDN (eg. "thisisthegame.here.now") that would reference through DNS setup on pfSense to get you across the VLANS.
So far, it seems to be working just fine with the bridge. Typing FQDN for children on handheld devices might be a bit much for them. Android complicates it more with their default hostnames that (sarcasm) seem to be deliberately constructed to test the buffer size limits of any DNS server. (I can control the DNS hostnames for the devices that "live" there, but not for the ones that are only guests.)
I think (hope) they are moving away from the minecraft phase anyway, so once that's gone, I can drop the bridge.
Another thought is to just write a quick daemon that listens for broadcasts on whatsoever port minecraft is using and retransmits the broadcasts on another interface. (I'd have to do packet captures to figure out exactly what is being broadcast.) A sort of broadcast forwarder. (Actually, something like that might already exist… hmm..) I'll freely admit that something like that would be COMPLETELY unsuitable for use on a larger LAN, but it might be a good learning experience for me even if it turns into a disaster.