Orbi RBRE960 forwards WAN PPPoE VLAN tag into the LAN

Orbi RBRE960 forwards WAN PPPoE VLAN tag (XXXX) into the LAN mid-flow, causing wired clients without VLAN-aware NIC settings to silently stall on long transfers.

Product

- Router: Orbi RBRE960, firmware V7.2.8.8 (Sept 2026)

- Satellites: 2x RBSE960 (wireless backhaul), same firmware version

Topology

- ISP: FTTH - ONT

- ONT in bridge mode: the Orbi itself establishes the PPPoE session directly against the ONT. PPPoE MTU 1492.

- VLAN setup on the Orbi: a single rule, 802.1Q tag XXX, applied to all wired ports and all wireless. The Orbi's

VLAN page does not allow restricting the tag to a single port.

- Satellites connect over wireless backhaul, not wired.

Symptom

On a long-running TCP flow from a wired LAN client to a WAN host, frames for that flow arrive untagged for approximately the first second. The Orbi then starts forwarding frames for the same flow into the LAN tagged with 802.1Q VLAN XXXX (the WAN-side PPPoE VLAN), sourced from the router's LAN-side MAC. Clients without a VLAN XXXX interface drop these frames at layer 2, before IP/TCP, so the flow appears to hang with zero throughput while the remote server keeps retransmitting (also tagged) until it gives up and sends FIN/RST, which go out untagged again. The failure is per-flow and time-fixed (~1 s into the flow), independent of throughput.

Steps to reproduce

1. Connect a Linux client directly to an Orbi RBRE960 LAN port (no intermediate switch).

2. Start a long download (multi-GB) from any external HTTP server, sampling throughput at intervals of 2 s or less.

3. Run `tcpdump -e` on the client during the download.

4. Observe: frames arrive untagged for ~1 s, then switch mid-flow to 802.1Q tag XXXX; the client drops the tagged frames (no matching VLAN interface) and the flow stalls; the closing FIN/RST are untagged again.

5. Alternative check on Windows: toggle the NIC driver's "VLAN Priority Tag" (or equivalent 802.1Q handling) setting between on and off while repeating the same long download. With the setting on, the driver accepts the tagged frames and the transfer completes; with it off, the same transfer stalls identically to the Linux case.

Evidence

- Reproduced independently on two different wired Linux hosts on two different occasions, including one connected directly to the Orbi's LAN port (bypassing all intermediate switches and cabling).

- Per-flow, time-fixed: a new flow started later in the session stalls again at the same ~1 s mark; stall timing is identical at low throughput (~2.5 MB/s) and high throughput (~30 MB/s).

- Windows control test, same port and cable: 1.37 GB transferred with zero stalls with "VLAN Priority Tag" enabled; the identical setup stalled at 36.6 MB with the setting disabled.

- Kernel counters on the affected clients show no checksum errors, no queue drops, no out-of-order drops at IP/TCP level: the loss is entirely at layer 2 (unknown-VLAN frames are silently discarded before reaching the IP stack, so standard network counters never see it).

What has been ruled out

- Router VLAN misconfiguration: checked, and the configuration matches what the ISP requires.

- Client/OS-specific bug: reproduced on two independent Linux systems with different NIC hardware, and shown to be driver-VLAN-handling-dependent on Windows.

- LAN cabling, switch port, or client NIC as the root cause: same port and cable produce success or failure depending only on whether the OS/driver processes VLAN tag XXXX.

- DNS, PMTU/MTU, TCP window scaling, SACK, timestamps, conntrack strictness: all varied independently on a client with no change in the outcome.

- Firmware downgrade as a workaround: the same behavior was already present on firmware versions prior to V7.2.8.8, per our own prior experience with this router.

Unconfirmed hypothesis

The point at which tagged forwarding begins (~1 s into a flow) is consistent with the flow being handed off to a hardware NAT/flow-acceleration path. We could not confirm this independently: enabling the Traffic Meter (reported elsewhere to disable hardware acceleration on some Netgear routers) did not change the symptom, but we had no way to confirm acceleration was actually disabled while testing.

Request

Please confirm whether this is a known issue, and provide either a fix (maintenance or beta firmware) or an official workaround — for example a supported way to disable hardware NAT/flow acceleration on this WAN VLAN path, or to ensure the ISP's VLAN tag is stripped before frames reach LAN ports. We can provide the tcpdump -e pcap captures referenced above on request.