Is there any real knowledge or documentation about working with VLANs on SonicWalls?

Answers

• Smash Newbie ✭

  May 2022

  I've gotten some good configuration ideas from this guy's youtube channel.

  
  

  (40) Jean-Pier Talbot - YouTube

  2
• TKWITS Community Legend ✭✭✭✭✭

  May 2022

  What you are looking for in Sonicwall's world are 'sub-interfaces'.

  https://www.sonicwall.com/support/knowledge-base/how-can-i-configure-sub-interfaces/170503889544086/

  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.

  1
• MrPalomar Newbie ✭

  May 2022

  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.

  0
• TKWITS Community Legend ✭✭✭✭✭

  May 2022

  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.

  1. Yes. This is standard behavior for any VLAN aware device. You have to remember VLANs are Layer 2, IP subnets are Layer 3.
  2. This is counterintuitive to the entire point of traffic separation via VLANing.
  3. https://www.sonicwall.com/support/knowledge-base/sonicwall-firewall-native-bridge-support/180107082554390/
  4. I cant even follow this line of thought...

  From your last paragraph you have a simple problem with an overly complex thought process on the end result. Some reading suggestions:

  1. https://en.wikipedia.org/wiki/OSI_model#Layer_architecture - the OSI models 'media layers' are extremely important to understanding topology, cabling, and addressing conceptualization and planning
  2. https://en.wikipedia.org/wiki/Computer_network#Network_topology - specifically star and tree topologies
  3. https://en.wikipedia.org/wiki/Virtual_LAN#Configuration_and_design_considerations - why VLANs are important to network design

  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...

  0
• MrPalomar Newbie ✭

  May 2022

  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:

  1. Of course VLAN-aware devices drop frames not tagged to the VLAN; I should have been more specific and put in "always". Some Layer 2 devices with ports assigned to a specific VLAN (the "Port VLAN", PVID) allow untagged frames and frames tagged with non-PVID; these are called trunk ports, and a port may be set to "trunk" mode, and there are lots of things you can tell that port to do, or not, depending on the VLAN tag that is (or not) in the incoming frame and other parameters. I don't see any discussion of anything like that in any SonicWall document I can find. SonicWall seems to confuse the notion of VLAN with the notion of "tag" and sort of use those terms interchangeably in some documents. If I want a physical port on my TZ370 to accept multiple VLANs, I have to create a virtual interface for each VLAN ID, one by one (true?). Not a problem, I only have a few. That's a SonicWall-specific question, not general networking.
  2. Is it really counterintuitive for a physical port to accept frames with a VLAN tag corresponding to the subnet of that same port but without a VLAN tag? If X7 is 192.168.123.1/24, and X7:V123 is NativeBridged to X7 on X7 (this is allowed), then should X7 accept frames whose source IP is 192.168.123.x whether those frames are tagged 123 or untagged. Some devices (e.g. a PBX or workstation needing to manage it) may send frames untagged, while others (e.g., a VoIP handset) may send tagged frames. My intuition says it's reasonable that this traffic should not 100% always be segregated and those devices prevented to communicate. Especially if I NAT an address object from X7 to X7:V123. Where can I find out how TZ370 handles tags? Not in the document that doesn't differentiate VLANs from tags, and not from your answer that ports on a VLAN drop frames not tagged with "the VLAN" because that's what VLANs do and I better go read about what a network is. I'm learning that NAT translations are applied in OSX7 while the tag (if any) is "off" the incoming frame and before the destination port for that frame is determined, so it makes sense intuitively - logically in fact - that a TZ370 port should be able to direct an untagged frame on 192.168.123.0/24 to a destination on 192.168.123.0/24 in VLAN 123.
  3. Thank you, I read that article again. More specifically: Why is NativeBridge ostensibly only for WLANs? Will a NativeBridge scenario like the one described above (no WLANs in sight) pass traffic from X7 to X7:V123, and vice versa, or not? More importantly, why and what's the sequence of steps? My mistake; I asked it that way in my support request.
  4. Sorry, I should have explained the context before asking the question instead of in the very next paragraph. Straightforward: Two buildings connected by a high speed wireless bridge (might as well be a single wire almost). One network, one ISP router (X1). Endpoints in the same 4 subnets on both sides of the wireless bridge. VLANs is "logical multiplexing" (read that in the SonicWall docs, great way to put it); traffic that needs to remain segregated (e.g., office/data, VoIP, security/alarms, IT, company management) can all go over the wireless bridge, that is exactly the point of VLANs, right? Still hard to follow?

  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.

  0
• TKWITS Community Legend ✭✭✭✭✭

  May 2022

  1. If I want a physical port on my TZ370 to accept multiple VLANs, I have to create a virtual interface for each VLAN ID, one by one? - Yes
  2. Is it really counterintuitive for a physical port to accept frames with a VLAN tag corresponding to the subnet of that same port but without a VLAN tag? - In my opinion, on a firewall it is. You can do all sorts of things with PortShield and Bridging, but why do that when we have switches. Where can I find out how TZ370 handles tags? - In the most basic terms, it handles tags like a 'trunk' port does on a switch except the PVID cannot be changed on the Sonicwall.
  3. I dont believe it is only for WLANs, that is simply how they decided to demonstrate it (also I'm sure it's been asked a thousand times because of the way they manage their APs). I have little to no experience using NativeBridging as I prefer to use dedicated equipment for bridging purposes (bridges / switches).
  4. That is the point of VLANs.

  "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?

  0
• MrPalomar Newbie ✭

  May 2022

  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.

  -Frank

  0
• TKWITS Community Legend ✭✭✭✭✭

  May 2022

  You're welcome. Feel free to throw your ideas this way and I (or others) can re-assess with you.

  1