We essentially do the same thing, and our firewall is a Watchguard 750e with Fireware Pro. Pro is not required for this, but its nice for the extra features. I would imagine Sonicwall should be able to do this with their enhanced OS, but I don't play with them much.
The only thing we really do differently is our Access Points are Vlan aware, so we tie the SSID to a vlan. This way our guests get VLAN 3 when they connect to the Public SSID and our staff get the VLAN 2 when the connect to the Corporate SSID. Eliminates the extra VPN step. Great explanation Ben, passing it on to some of our junior techs who are not fully up on VLAN technology yet. Thanks Greg -----Original Message----- From: Andy Ognenoff [mailto:[EMAIL PROTECTED] Sent: Wednesday, December 10, 2008 10:14 AM To: NT System Admin Issues Subject: RE: VLAN concepts and applications Nice explanation - can I ask what firewall you use with this setup? I've got a SonicWall Pro 2040 and looking at the ProCurve 2810's to do a similar setup. - Andy O. >-----Original Message----- >From: Ben Scott [mailto:[EMAIL PROTECTED] >Sent: Tuesday, December 09, 2008 7:39 PM >To: NT System Admin Issues >Subject: VLAN concepts and applications > > Someone asked me off-list for an explanation of some VLAN stuff. >They agreed to let me post my response to the list, for discussion, >review, etc. If anyone has corrections/additions/etc., please >contribute. > >PROTOCOL CONCEPTS > > We have regular "untagged" Ethernet frames. ("Frame" is the >data-link (layer 2) term for what some protocols calls a "packet" or >"datagram".) These are the same Ethernet frames from before VLANs >were invented. > > Then we have "tagged" frames. These take a regular Ethernet frame >and add a marker -- the "tag". The tag itself contains the VLAN >number (along with a priority code). Thus, a tagged frame is >associated with a particular VLAN number. > > Inside the frame, the tag is basically just a reserved Ethernet >frame type, followed by the tag information, followed by the rest of >the original frame (complete with its original frame type). So to >network nodes which are *not* VLAN aware, a tagged frame looks just >like a regular Ethernet frame, but with an "unknown" frame type. > > For computers, a VLAN-aware network stack will usually turn each >VLAN into a separate network interface, as if each VLAN was a >different network card with a different cable. The "stock" network >stack included with Win 2000/XP does *not* include VLAN capability, so >they can only handle untagged frames. Tagged frames will generally be >silently ignored. Third-party software (often included with high-end >network cards) can add VLAN capability. I'm not sure about >2003/Vista/2008. > > Switches which are not VLAN-aware, along with any repeaters, will >treat tagged frames exactly like they do any other frame. > >SWITCH CONCEPTS > > Switches which are VLAN-aware generally let you control which ports >are associated with which VLAN(s). The terminology, commands, etc., >will vary with manufacturer. I'm most familiar with the HP ProCruve >managed witches, so I'll speak mostly to that. The concepts should >carry over to other manufacturers. Hopefully others can chime in with >specifics. > > With HP, you can tell the switch that each VLAN is tagged, untagged, >or not available for each port. Internally, frames are *always* >associated a VLAN number. The configuration just tells the switch >which VLANs go with which ports, and which VLAN number to use for >untagged frames. > > When the switch receives an untagged frame, it needs to know what >VLAN to associate it with. If the port has an untagged VLAN >associated it, the fame will go to that VLAN. If there is no untagged >VLAN associated with the port, the frame is dropped. This is why a >port can have (at most) one untagged VLAN associated with it -- how >could the switch know which one to use otherwise? > > When the switch receives a tagged frame, it simply checks to see if >that VLAN is associated with the port. If so, it accepts it; if not, >it drops it. This is basically just an access control mechanism. > > When the switch has a frame to *transmit*, it only considers ports >which are associated with the frame's VLAN. If a port is configured >as tagged for the frame's VLAN, it transmits the frame with the VLAN >tag. If a port is configured as untagged for the VLAN, the frame is >transmitted on that port without a VLAN tag. > >APPLICATIONS > > Okay, enough conceptual stuff, how do we use it? > > At %DAYJOB%, we've got VLANs as follows: > >1 - Reserved >2 - Main company private network >3 - Guest network >4 - ISP uplink >5 - IP telephony > > We don't use VLAN 1 because that's the default on most things, and >to avoid confusion we avoid it. > > VLAN 2 is where most traffic is. Most ports are configured as >untagged for VLAN 2. The computers, printers, etc., plugged into >those ports aren't even aware they are on a VLAN. All the employee >workstations are like this, as are most servers. The syntax to >configure this is easy. For example, if I want port 1 to be untagged >for VLAN 2 like this: > > vlan 2 untagged 1 > > VLAN 3 is for guests (visitors). For obvious reasons, we don't let >them plug in to our main network. They get a separate IP subnet, a >separate DHCP server, and bypass much of our network filtering. This >is also where our wireless access points connect (employees use >VPN-over-wireless). Again, all untagged, and connected nodes are not >aware of the VLAN. > > VLAN 4 exists because we've got a cable Internet feed we use for >employee web browsing. Circumstances meant the cable modem had to go >in a different building from the main server/network room. (We have >another feed for important stuff; that terminates in the server room.) > So the cable modem plugs into a particular switch port, which uses >VLAN 4 to carry it to our firewall in a different building. Again, >untagged, unaware. > > VLAN 5 is for premises voice-over-IP, a project which I'm still in >the middle of. My plan is to let the phones be VLAN-aware and tagged >everywhere, so they operate "outside" the regular network. In theory, >it should be possible to have a phone tagged on VLAN 5 and a computer >untagged on VLAN 2, both on the same port, as follows (example uses >port 7): > > vlan 2 untagged 7 > vlan 5 tagged 7 > > I am using separate VLANs for security, manageability, and >robustness. I don't want guests to be able to probe/sniff/screw-up >the corporate network. They can't. I don't want the cable modem link >(which is full of garbage traffic from other subscribers) on the main >LAN. It isn't. I want the phones to have higher priority over >regular data, and to have their own DHCP server. Haven't got that far >yet on that one. :) > > For links between switches, each VLAN is configured as *tagged* for >those ports, with *no* untagged VLAN. Those ports are only used to >carry traffic between VLAN-aware switches. (Cisco would call this a >"trunk port", IIRC.) The HP syntax for (e.g.) port 24 as a switch >link would be: > > vlan 2 tagged 24 > vlan 3 tagged 24 > vlan 4 tagged 24 > vlan 5 tagged 24 > > Finally, our firewall, which *is* VLAN-aware, is configured as >tagged for all VLANs on its port, with no untagged VLAN. Virtual >network interfaces are configured in the firewall OS, and all the IP >configuration and filtering rules are done with those virtual >interfaces, not the physical interface. This also means our firewall >only has one network cable plugged into it. Configures the same as a >switch link, really. > > Hope this helps someone! > >~ Finally, powerful endpoint security that ISN'T a resource hog! ~ >~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~
