Orbi Pro 6: Default VLAN, Native VLAN, VLAN Hopping

---

AquaLabAquaria wrote:

My understanding is that leaving devices on the default vlan is not a great practice, and that it shouldn't be used for management either.

---

A problem still in many old minds and the Internet caused by historic switches (not only by Cisco IOS) limitations and/or bugs where the there was such a hard coded native VLAN - history.

---

AquaLabAquaria wrote:

However, it does not seem like it's possible to change the native vlan tag nor is it possible to move the router and satellites off the native VLAN profile.

---

it simply makes no sense - for usability and simplicity of the deployment of these devices It's the default untagged [V]LAN which is mapped to the VLAN 1 as represented by the LAN 1 profile.

In a typical deployment, most "everything" is operating on one VLAN which is accessed untagged by devices - if this is internally named LAN 1 and is the VLAN 1 or the VLAN 1234 does not make any difference.

---

AquaLabAquaria wrote:

The LAN 1 must be bound to the Default (1) VLAN profile, and this LAN seems to contain all the router and satellite hardware on it (sort of what should be the management VLAN).  The native VLAN also appears to use this VLAN profile as indicated by the instructions from Netgear to assign the Default VLAN profile to all the ethernet backhauls from satellite to router. What is the recommendation here since it does not seem like the native VLAN can be changed nor can I take the management VLAN off the default VLAN profile.  Are Orbo pro 6 vulnerable to VLAN hopping exploits?

---

Wait a moment. If you are going to operate multiple WLAN and VLANs on the router and the satellite, the connections from the router to the satellites making up the trunk(s) run the "primary" VLAN untagged [I am intentionally avoid the native VLAN designation as it does not apply here!] and all other VLANs are tagged. Here it does not matter if these are direct wired connections, or of there are VLAN capable and appropriately configured switches in the distribution tree from the Orbi Pro 6 router to the Orbi Pro 6 satellites. 

VLAN hopping is done by injecting frames with other VLAN tags on an untagged [any vlan] port, or on  trunk port where tagged frames are allowed. To my knowledge, there is no control to configure a port for not accepting tagged frames (e.g. on a port assigned to an untagged VLAN), or to make tagged frames mandatory (what does deny the simplicity if the design approach allowing one VLAN to be run untagged).

Needless to say, each port must only allow - as per its configuration - either untagged frames, or only tagged frames as configured and nothing else. BruceGuo please.

---

AquaLabAquaria wrote:

Furthermore, is it correct to say that LAN 1 is made of L3 ports and essentially laid out in a linear topology, with a trunk connection between each port and to the WAN.  Am I thinking about this properly?

---

Not sure it's limited as you think. Re-read my above text please.

---

AquaLabAquaria wrote:

If so, that means inter-vlan routing is possible (this is also suggested by the fact that network isolation can be turned on and off).   What is the best way to think about the network isolation setting, inter-vlan routing, and wether or not the Orbi Pro 6 router can act like a L3 switch.

---

As i wrote in another reply where you followed up.

"... In my understanding, the controls are limited to the "network isolation", so it's less than what is available on a simple L3 smart switch. The KB How do I create, configure, and assign VLANs on my Orbi Pro WiFi 6?  says. "When network isolation is enabled, clients in this VLAN cannot communicate with clients in other VLANs." ...".

Reality check for the typical deployments here? People are evaluating risks and read a log of say for example a guest network or an IoT network should be isolated from the normal work environment - and jump the boat here buying Orbi Pro 6 system, and set-up a proper isolated networks first. Then the "problems" arise. Their mobile phones can't discover or control IoT because these are on a different VLAN, perfectly isolated. Their guests can't just use the printer because it is on the normal work network. And so on ... 

Key point is that for the security people a real IoT is an isolated device, only able to talk to it's cloud, and all interactions happen over the cloud. Now we have wonderful say building and light control systems. All the smart IoT push button devices in reality talk direct to their activators, or they talk to an IoT controller on the network which does handle the logic. So these devices require direct connection on the netwok, so the isolation must be disabled. The next things are controller apps, here again these need to talk from the normal network to the IoT network, to reach controllers, activators, from the mobile phone, where also normal workstation are, normal local or cloud storage is done. The point is that such designs are washed up in a short time

What is in the works is an Multicast routing feature while talking, so LANs where communication is allowed will be interconnected for Multicast discovery, IGMP stream handling, ....

Much more than what the books at the IT security university are talking of...