Is there any real knowledge or documentation about working with VLANs on SonicWalls?
I'm trying to configure VLANs on my network, which has a TZ370, Adtran 1560 Layer 2 managed switches, and a Ubiquiti AF60 high speed wireless bridge. This is all leading edge equipment with the latest firmware and functionality. What's missing is decent detailed documentation about VLANs, tagging, port bridging, and related Interfaces, Objects, Policies, monitoring/testing; in other words the information required to design and implement a standard network just one level above the most basic trivial architecture. I've been through all the Sonic OS7 manuals; I've surfed the support part of the site; I've tried to speak with sonicwall level 2 tech support, I've searched in here for the term VLAN, which should produce more posts than a person could read. There's just very little information about any of this. Sorry, my questions can't be expressed in tweet format; it takes time to explain it in a useful way; before I do more of that, can anyone tell me where to find substantive actual knowledge about this? I don't need the knee-jerk links to search results - I've been through all that and it's weak at best. There should be people at SonicWall who are actual experts in this stuff; how do I contact them? Standard support is not the answer, been there, done that. There doesn't seem to be an escalation path, just a lot of resistance and checklist-reading. Where's the real knowledge please, how do I access it?
I've gotten some good configuration ideas from this guy's youtube channel.
(40) Jean-Pier Talbot - YouTube
What you are looking for in Sonicwall's world are 'sub-interfaces'.
Each subinterface is assigned a VLAN. This in turn makes the parent interface (commonly X0) what is commonly referred to as a 'trunk' interface (as opposed to an 'access' interface).
It's also important to take into account the Zone-based firewall system Sonicwall uses. Each subinterface should have it's own zone, which you can then apply Access Rules to for traffic control.
Hopefully that gets you on the right path.
Thanks, much appreciated. I did figure out how to click on "add a new interface" and use dropdowns and click OK. So I think I'm already on the right path, but I think I've taken that path as far as it goes, and beyond because I keep doing trial and error hoping to discover facts about how OSX7 works, deduce consistencies, etc. What I'm trying to find is the *next level* of knowledge. For example:
• On a virtual interface (which by definition has a tag ID), does that interface ignore packets that are not tagged with the VLAN ID, even if those packets are on the associated subnet?
• If I want the subnet associated with the VLAN ID of a virtual interface to be the same as the subnet of the parent (or some other) physical interface, should I make the VLAN virtual interface the secondary of a NativeBridge to the desired physical interface? or vice versa? Can NativeBridge do this association between physical and virtual interfaces all in the LAN zone, in spite of the only documentation about NativeBridge saying that NativeBridge is for WLANs? The interface allows NativeBridge to be configured between two non-WLAN interfaces, and there's nothing in that sole article that precludes it except the initial chitchat about "what it's for".
• What does NativeBridge actually do, in detail?
• If I try to add a second/additional virtual interface on another physical port with the same subnet as the first one, the only thing the interface allows is to "bridge" the new virtual interface to the existing first virtual interface - not assign an IP or subnet - the new virtual NativeBridge secondary has an IP address of 0.0.0.0. What will that new virtualnativebridge interface do with incoming packets with source IP on the subnet of the primary bridge pair member (the virtual interface with the desired subnet)? Accept? Tag? Untag? Route? What will it do with other incoming packets? Does it matter what the destination IP is? Does this virtualnativebridge0.0.0.0 interface actually do anything or does it just sit there in the UI and not accept, process, transmit anything?
These are not idle questions. What I'm trying to achieve is a straightforward topology where the TZ370 is at the center of a network with a single set of several subnets/VLANs whose traffic needs to remain segregated (except for my IT management traffic which needs access to everything). The TZ370 is on a physical segment with devices on all subnets; there is a high speed wireless bridge on the other side of which from the TZ370 are some devices on all subnets/VLANs as well. So all traffic from the other side has to travel over the wireless bridge and on its single wire on each end. You can see the need to do the "logical multiplexing" of having traffic from multiple subnets/VLANs going into and out of single physical interfaces, and the need for the TZ370 to parse the traffic and route each subnet/VLAN's traffic to the physical or virtual interfaces dedicated to each subnet/VLAN. And vice versa.
I'm trying to find either sufficient documentation so I can figure out how to accomplish this; or a person who can a) comprehend it, b) knows how to make a TZ370 do it all, and c) can explain it properly in spoken or written english.
Any guidance from the community toward this is most appreciated.
This query is much more about general network design and engineering than specific Sonicwall items. That said I will try to touch on each point.
From your last paragraph you have a simple problem with an overly complex thought process on the end result. Some reading suggestions:
I'll end with these thoughts: try to use only one physical interface with multiple sub-interfaces (VLANs) on the Sonicwall for your internal networks; use only one subnet per VLAN.
I'm just going to also state that I do not like giving answers without context and learning. Admins must understand what they are doing and why, not just follow a guide someone posted on the internet...
First, thanks very much for your reply. I appreciate the thought and effort behind it. It's a good observation that the concepts of networking are partially what's driving my questions. I've had a little time to look at your suggested links and do more reading. To follow up:
I think VLANs is the right way (because it'll reduce broadcast traffic), maybe the only way (without an additional router added to the mix) to handle this situation. The TZ370 side of the wireless bridge could I guess go into a trunk port on the switch instead of to a port on the TZ370; then the switch would have to slice and dice the traffic to its ports connected to the SonicWall's ports on the intended subnets; that way some of the traffic would never hit the TZ370 because the destination would eventually be in an ARP table in the switch. But it's not clear to me how traffic would find its destination on either end because as far as Layer 2 knows, the only next destination is the other side of the wireless bridge. I think. This is why I'm asking these questions.
What I don't follow is your bit about giving answers without context and learning. I've provided context multiple times; have you learned from my questions, is that what you mean? Was I supposed to just follow the generic guides you merely posted on the internet? My questions are designed and carefully crafted to help me learn how to do what I know well what I want to accomplish; the why is so people can do their work. I don't like spending the time and effort to ask focused, relevant, articulate questions without the context of people able to comprehend, who know the topics (networking and SonicWall OSX7 in this case), are able to answer without sending me to generic internet links. That's why the original post title is what it is.
"The TZ370 side of the wireless bridge could I guess go into a trunk port on the switch instead of to a port on the TZ370."
That is what I was trying to guide you to. Use the switches and the wireless bridge for their intended purpose: to expand layer 1 and 2. That is simplest, most effective way of obtaining your goal. Introducing unneeded Layer 2 complexity into the firewall configuration will make it more difficult to maintain.
Firewall <-> switch <-> wireless bridge <-> switch
You didn't get my 'bit', but that's ok because you got to the best conclusion. So in the end you did, though it seems you didn't realize it.
Any other questions?
Thanks again, I really appreciate that you spent time and effort with my posts. I'll take another hard look at putting the wireless bridge into the switch; it sounds like that's the best practices way to do it.
Again, thank you for your help.
You're welcome. Feel free to throw your ideas this way and I (or others) can re-assess with you.