@mbze430 

you are trying to use a product for something it is not designed for. i don't know if you bought this router to have backup wan or if you bought it to have wifi outside and at the same time have backup wan.

anyway it is a router, it is only possible with one router per site, yes that is the case with unifi too, so if you need to use it as a backup wan connect it to a wan port on the ER8411 and set up failover. then you buy yourself an access point to use outside.

  @MR.S 

 

MR.S wrote

  @mbze430 

 

you are trying to use a product for something it is not designed for. i don't know if you bought this router to have backup wan or if you bought it to have wifi outside and at the same time have backup wan.

anyway it is a router, it is only possible with one router per site, yes that is the case with unifi too, so if you need to use it as a backup wan connect it to a wan port on the ER8411 and set up failover. then you buy yourself an access point to use outside.

 

 

Think about what you just wrote. If this unit wasn't intended to act as a backup/primary WAN with the secondary purpose of providing Wi-Fi to extend coverage, why would they put both of them together in a single chassis? They would have just made a standalone cellular router and be done with it.

Suggesting I buy a standalone AP and run a second physical drop to the exact same outdoor location completely ignores basic enterprise design. Why would I pull two cables and waste edge switch ports when a single solid-copper trunk line can handle management, a cell-transit link, and multiple user data planes simultaneously using 802.1Q tagging? We don't solve software limitations by throwing unnecessary copper and hardware at a patio. Imagine your thoughts applied to the real world—our streets would be littered with cables.

If you strip away all the GUI, basic networking still applies. The problem isn't the hardware capability; it's a software wall that TP-Link built that is hindering it. For example, after multiple attempts at moving the management interface off the default VLAN, it seems the system daemons will always rigidly bind to whatever IP the "Default" VLAN is holding. As a Cisco Network Administrator, the first thing we do is disable VLAN 1 and create a black hole; normally, we isolate the management plane into a dedicated mgmt-VRF.

Anyway, after realizing the quirk that requires checking the "Gateway" hardware target box, I was able to get all the SSIDs to work with the rest of the network. The interface completely fails to explain that this checkbox defines the hardware scope for the profile. In an enterprise environment, a "Gateway" is a Layer 3 routable boundary, so my initial thought was that the option was meant for some form of wireless point-to-point routing.

Furthermore, the kernel needs to instantiate a Virtual Ethernet (VE) interface for each SSID to actually bridge the Layer 2 traffic out the wire, but nowhere in the wireless menu is that configuration step exposed. Thankfully, the companion wired profile workaround forces the controller to do it anyway.

TPLink Mod or Engineers

I have a huge security concern right now, and VERY hesitant to put it in the field.

Because I can only get the "adopting" mechanism to work in the Default Vlan (untagged).  That means anyone can get to the cable plug in their device and hack away at the switch and the entire vlan.  Even if the switch has mac filtering or 802.1X enabled wouldn't work, because literally the MAC address is on the outdoor unit.  If I deface the label, will you guys still warranty it?

You must tell me a way to transfer the adopting/management plane over to vlan I can tag; which you do have in your switch and EAP products but not your router/gateway products.  And untagged traffic into a blackhole.  At least there is some resistance.  This is WAY too open.

  @Gabriel-TP 

Thanks for the official confirmation. Let’s cut straight to the architectural reality: telling an enterprise network engineer to use L3 ACLs and firewall rules to fix a fundamental Layer 2 isolation deficiency on an outdoor device is a band-aid, not a solution.

This model is literally named the ER703WP-4G-Outdoor. It is designed to be mounted outside on a pole, a facade, or a remote mast, entirely outside the physical security perimeter of the building. By locking the Omada Controller mode into forcing the primary management plane to run untagged traffic only, TP-Link is introducing a glaring physical security liability.

The Security Risk: Physical Exposure = Network Exposure

In any hardened enterprise posture, any network line leaving the physical security perimeter of a building is untrusted. Standard engineering practice dictates:

1. The upstream switch port (in our case, an SX3206HPP) has its Native PVID set to a non-routing black hole (like VLAN 4000).

2. The port is configured to completely drop all untagged frames.

3. All legitimate management traffic to the edge device must be strictly 802.1Q tagged on a secure management plane (VLAN 254).

Because the Omada Controller forces the ER703WP to keep its management handshake untagged, I am forced to leave the native VLAN alive on that outdoor physical wire.

This creates a textbook "Hot Drop" vulnerability. If an attacker physically tampers with or unplugs that outdoor unit and jacks a laptop into that RJ45 line, they are instantly dropped straight into the corporate Management Subnet. They don't have to sniff packets or guess a tag—the controller forces us to serve the management plane to the physical wire on a silver platter.

Proof of Concept: The Hardware Can Do It, The Controller is the Wall

Your engineering team asserted that this scenario is impossible because the device lacks "WAN IP Passthrough." That is incorrect. The hardware pipeline handles this layout perfectly right now; it is the rigid logic of the Omada SDN Controller that is blocking standard deployment.

I have already bypassed your software limitations and forced this exact topology into production using the following site configuration:

• The Multi-Site Bypass: To circumvent the controller's arbitrary "one gateway per site" rule, I duplicated the profile to a secondary "Backyard" site just to adopt the ER703WP.

• The L3 Routing Workaround: To satisfy the controller's rigid requirement for a local routing engine without bleeding into our production space, I provisioned a dummy, non-routable Class C subnet on an internal virtual interface (VE) for VLAN99 (Cellular backup), and every SSID VLAN that needs to be outdoor.

• The L2 Trunk Execution: This trick freed up the physical pipeline. I successfully assigned a static IP to the ER703WP (10.3.99.49) and built a clean point-to-point Layer 2 trunk over VLAN 99 directly to our core ER8411 gateway (10.3.99.50) for the cellular transport. Wireless SSIDs are passed cleanly back to our core L3 switch fabric (a Celestica running SONiC) using "VLAN-Only" networks.

The device is handling the traffic exactly how I want it to. The hardware isn't the problem—the software is.

The Required Fixes for the Product Team

If TP-Link wants Omada to be taken seriously in enterprise and industrial spaces alongside Cisco, Aruba, or UniFi, the development team needs to implement two basic software toggles in the next firmware cycle:

1. True 802.1Q Management Tagging: Changing the "Default" network VLAN ID must actually tag the egress management frames and allow users to completely shut down and drop untagged traffic on the faceplate ports. Shifting the internal native PVID while continuing to blast untagged frames down an outdoor wire is a failure during security audits.

2. A Dedicated "AP + Cellular Bridge" Mode: Forcing an engineer to configure a convoluted, dummy L3 gateway architecture just to utilize an outdoor cellular radio as a backup link is clumsy. The ER703WP needs an operating mode that disables its internal local DHCP/routing, treats the management plane exactly like a standard EAP-series access point, and bridges the raw cellular connection straight down a user-defined tagged 802.1Q VLAN interface.

Your customers shouldn't have to design convoluted, non-routable dummy networks just to bypass artificial software constraints on "business-class" hardware. Please pass this specific implementation and the physical security exploit risks back to your product managers.  If your engineering team like to see my Omada Configuration I am happy to provide that privately.