NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
CrimpOn
Mar 27, 2025Guru - Experienced User
VLAN Puzzle
I would appreciate assistance diagnosing a VLAN problem. Now that many homes have Ethernet cables installed from most rooms to a central patch panel, some users find that the patch panel is not a gre...
CrimpOn
Apr 12, 2025Guru - Experienced User
A common situation for people with 'wired' houses is having only a single Ethernet cable from the central patch panel to each room. Placing a simple switch in that location allows many devices to be connected to the network. However, there is one specific application that does not work. Often that central patch panel location is not suitable for a WiFi access point and users would prefer to locate their WiFi router in a different room. This works great as long as the Orbi satellites are connected to the router using the default WiFi connection ('backhaul'). Netgear Orbi routers are designed to expect the ISP connection to appear on their WAN port and any 'wired' satellites on the LAN ports. Thus, connecting a satellite to the router with Ethernet requires another Ethernet cable. This is often inconvenient or very expensive.
One solution is to place one managed switch at the patch panel and another managed switch at the router location. Using 802.1Q VLAN tagging, the single Ethernet cable can carry both the WAN connection and the LAN connection:
In attempting to discover what causes this solution to fail, the following experiment was conducted:
- Using a single Netgear GS105Ev2 managed switch, connect a router LAN port to one port and the satellite to a different port. (see below) i.e. do not utilize the 'tagged' VLAN ports for the WAN connection.
- With this configuration, everything works except when attempting to connect a device to the Guest WiFi. That fails. The device generates DHCP requests that are visible on Tap2, but those DHCP requests do not appear on Tap 1. They do not get through the managed switch!
The solution is to change from Advanced VLAN to an ordinary Port Based VLAN. i.e. put ports 1 and 5 in VLAN 1 and ports 2,3,4 in VLAN 2. Then, a device connected to the satellite Guest WiFi sends DHCP requests that go trough the managed switch to the router and the device receives a Guest WiFi assignment back from the router.
This "solution", of course, is not a solution at all because it does not account for the WLAN traffic that needs to be separated from the LAN traffic by using an 802.1Q 'tagged' VLAN connection between a pair of switches.
Can anyone suggest how to configure a Netgear managed switch to make this work?
p.s. now that I have invested in multiple Ethernet taps, the next step is to set up the original proposed solution again and monitor "both ends" to see if any packets are being dropped.
schumaku
Apr 12, 2025Guru - Experienced User
Dear CrimpOn
The point is that -we- (or at least me...) don't know what fancy tricks and probably undercover standards are affecting the functionality of these Orbi Systems - especially in AP mode. Trial-and-error reverse "engineering" attempts won't bring us much forward.
The point is your post does imply a potential "problem" on these very simple Web-configurable switches (ways off from Netgear Smart Managed or Managed Switches).
The more likely cause is hidden somewhere in the Orbi in AP mode requirement, having the WAN port connected to the router LAN, while the satellites seemingly -must- be connected direct to the Orbi Router LAN.
That much, this is not more than reading in the coffee grounds. Admit, your effort investing in to Ethernet Taps with Wireshark ports is impressing. Have offered my time, experience, and know-how to Netgear on almost any Orbi Beta without success. For my part, I won't invest my money in Orbi Systems - especially because of the lack of Netgear Engineering backing all over here to the customer base.
Happy weekend!
-Kurt.
- CrimpOnApr 12, 2025Guru - Experienced User
I am resigned to the possibility that Netgear has programmed something into the backhaul communication protocol that fails when put into AP mode. The point of this experiment is to document "what's different" in the data stream between the two modes. The immediate issue is my lack of understanding of 802.1Q VLAN methodology. The original experiment has been side-tracked by the damn managed switches.
Unless the results are incorrect (always a possibility), it appears that:
- When the GS105Ev2 is set up as a Port Based VLAN, a broadcast packet that comes in on any port that is part of VLAN 2 goes out every port that is part of VLAN 2. Just what one would expect. The problem is that I need to connect two switches with a "tagged" VLAN connection.
- When the switch is set up as an "advanced" 802.1Q VLAN, a broadcast packet that comes in on one port that is labelled as VLAN 2 does not come out the other ports that are labelled VLAN 2. That seems ridiculous. I haven't gotten to the "tagged" port at all.
Looking for next steps:
- Hoping someone watching this Netgear forum will offer insights.
- Could open a case with Netgear support on the new GS105Ev2. (confidence level not high.)
- Could replicate this simple experiment with a TP-Link managed switch.
- Is there another forum, perhaps on Reddit, where someone might have experience with 802.1Q VLAN?
- schumakuApr 13, 2025Guru - Experienced User
Leave it in port based, connect the tap, enable and use the guest VLAN. Almost convinced you will see tagged frames for the guest network 8-)
- CrimpOnApr 13, 2025Guru - Experienced User
Appreciate very much your patience in staying with this discussion.
The two issues remain under investigation:
- How to carry both the WAN traffic and the LAN traffic over a single Ethernet cable
- How to get Orbi functions to work correctly over this configuration (Guest WiFi, AP mode)
Performed a test of using Port Based VLAN to connect the two managed switches:
This "almost worked". The Orbi router had a network connection (to my primary Orbi network). However, there were two glaring issues:
- The Orbi router Attached Devices page began displaying devices connected to the primary network, along with their 192.168.1.x IP addresses. Because it is attached to the primary network, this Orbi router changed its LAN to 10.0.0.x (the default behavior). It was quite a shock to see all these 192.168.1.x devices showing up.
- This Orbi router appeared on the primary network as device 10.0.0.1 (IP on its LAN.)
It appears that the "Advanced" Port Based VLAN is capable of directing packets from one managed switch to the other over the single cable, but when they get to the other switch they get sent out whatever port the switch decides is appropriate. i.e. broadcast packets go out every port. unicast packets go out the port that has a MAC in the routing table that matches that unicast. So the router can talk to the primary network. Devices on the 10.0.0.x network can go through the router to reach the primary network (and the internet).
Even though they are 'managed', these are Layer 2 Ethernet switches. They neither know nor care about IP addresses.
Part of me says, "who cares?". So the Attached Devices pages on both the primary network and this sub network pick up traffic that is not relevant. If this router had been connected directly to the ISP (rather than to my primary home network), then it would be collecting broadcast packets from other customers on the ISP network. And, the ISP would be seeing packets that come from my LAN, rather than that pass through the router NAT process. oops!
So, in addition to being ugly, this Port Based VLAN solution might result in untended consequences regarding the ISP.
At this point, it appears there remain two choices:
- Go back to the 802.1Q VLAN approach and find someone who can tell me how to set it up correctly, or
- Look for a "smarter" managed switch. I'm almost $300 into this project so far. The budget might stretch a bit more.
Thanks for listening.
- FURRYe38Apr 14, 2025Guru - Experienced User
CrimpOn wrote:
I am resigned to the possibility that Netgear has programmed something into the backhaul communication protocol that fails when put into AP mode. The point of this experiment is to document "what's different" in the data stream between the two modes. The immediate issue is my lack of understanding of 802.1Q VLAN methodology. The original experiment has been side-tracked by the damn managed switches.
Looking for next steps:
- Hoping someone watching this Netgear forum will offer insights.
- Could open a case with Netgear support on the new GS105Ev2. (confidence level not high.) You won't get anything from NG support. I've already mentioned that I've been in contact with two different NG engineering level people in the switch domain during two different betas and both said this was a Orbi issue, not a Switch issue.
- Could replicate this simple experiment with a TP-Link managed switch. In the interest of testing this on a different branded managed switch, I tested this yesterday with a HP ProCurve 1810 series managed switch. Had 3 devices connecting WiFI at the RBS on the main WLAN fine and no VLAN config needed. However attempting to connect to the Guest Network, iPhone keep spinning attempting to connect but never connected, a Laptop connected to it but said No Internet, a Android pad avoided connecting altogether and only connected to the router Guest Network signal. I attempted a VLAN config tagged on all ports and still no devices got connected to the Guest Network successfully while Orbi BE series is set for AP mode using WAN port connection to host router. Lan port to switch and RBS connected to switch.
- I'm wondering since GN is tied to the WAN port natively and not behind any firewall, what would be causing GN to fail in AP Mode with RBS connected with a managed switch in between the RBR and RBS. Only in this configuration does this fail. Something on the ethernet backhaul with Orbi in AP mode and Guest Network seems specific and a Managed switch interrupts this in between the router and satellite units.
- Main resolution will be to put in a non managed switch in between and in most cases, the average Orbi home user won't have a managed switch, some may have, but generally won't have one. And for support resolution, I've always recommended using non managed switches for forum support help, best practice, and troubleshooting for RBS ethernet connected to a switch in between. So I presume with NG switch engineering knowing this is a Orbi issue and only in this configuration with a managed switch and with ease of resolution of using a non-managed switch in this configuration, I presume NG may not delve into this to fix it as this is really not a major issue lots of users. My 2 cents.
- CrimpOnApr 14, 2025Guru - Experienced User
Thanks for testing the HP switch. I agree that most customers have no reason to spend extra to purchase managed switches. This one situation is a "perfect storm":
- The patch panel location is a horrible place to locate the Orbi router. (could be in a basement) and
- Installing a second Ethernet cable to the desired location could be prohibitively expensive.
In that one situation, a pair of managed switches for under $50 (TP-Link or under $150 for Netgear) would be a quick solution. "no muss. no fuss." Even then, it appears that managed switches solve the problem unless the Orbi needs to be put in AP mode and there is a need for Guest WiFi.
Related Content
NETGEAR Academy

Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!