Internal VLANs
djhurt1
Enthusiast ✭✭
My understanding is that the firewall uses internal VLANs for each interface. Ours starts at the default 2. So for example if I have a sub-interface on VLAN 10, shouldn't I see traffic on X8 interface? Currently I do not but I'm curious what I'm missing.
Category: Mid Range Firewalls
0
Answers
On sonicwalls you can add Vlans to an Interface by adding virtual sub-interfaces.
https://www.sonicwall.com/support/knowledge-base/how-can-i-configure-sub-interfaces/170503889544086/
Your understanding is incorrect. VLANs are not auto-assigned to each interface. You have to create the VLANs. Even then you cannot change the 'default' or 'primary' VLAN of an interface.
Read up on sub-interfaces, VLANing, and port-shielding.
I got this notion in my head from this statement:
Every single interface on the firewall is separated by using VLANs internally. By default, it starts at 2. In SonicOS 7, the default vlan id starts at 3968.
If you are configuring/using VLAN sub-interfaces on the switch directly connected to the firewall using the same Internal VLAN ID, it might cause unexpected issues.
From firmware version 6.5.3.x onwards, we can now configure the internal VLAN so that they do not overlap with other VLANs connected/configured on the firewall.
I got this from a couple different sources but one was at https://www.sonicwall.com/support/knowledge-base/how-to-change-the-internal-vlan-id/200506072833850/
Note the end of the linked article it states "We cannot assign VLANs to each of the interfaces separately."
Also note this is referring to 'internal VLANs' with no real explanation of an 'internal VLAN'...
Maybe this doesn't come in to play when using regular interfaces and VLAN sub-interfaces. Perhaps it's more relevant when using VLAN trunking and link aggregation.
I've never had the need to do trunking in SonicOS before, but I now have a use case for it so was researching this topic. I'll change the reserved VLAN range just in case as I'll be using IDs from the default range.
Noteworthy is that a VLAN ID for an interface can't be changed if it isn't in a PortShield Group. So internally it looks to be used for separating interface traffic in PortShield switching scenario. I suspect using PortShielding and VLAN trunking at the same time could cause traffic ending in the wrong places if the IDs overlap.