@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.