Hello @Brian312,

You may set the Gateway IP on the EAP, and then set a port forwarding rule for EAP's IP address on the Router.

The port used for EAP is 80/443 by default, you may change it on the web interface of EAP.

  @Brian312 

You could also purchase a cloud controller license and add the AP to that controller/site which will work better than the port forward suggested above, because Starlink uses CGNAT which means there's no public IP that's usable from the outside.  If you can add just 1 piece of hardware, then adding a local OC200 between the starlink and the AP will achieve the same thing with a one-time cost (the downside is it will limit your aggregate up/down speeds via the AP to about 90Mbps as the ports on the OC200 are only 100Mb capable).

  @Brian312 

Hmm, Fibe and Starlink, that sounds very familar :)  Why not do this, using the public IP you have on your Fibe service ideally with a DDNS so your can use somedomaincom instead of a fixed IP which does change with Fibe on power cycles, then set up your controller, OC200/300 or software, locall inside the Fibe private network.  Open the required ports in the Fibe firewall, for Omada management traffic, I believe there are 4-5 ports.  Now program your remote AP with the public information of the Fibe based controller.  Your AP will reach out through the CGNAT and the internet to find your controller behind your Fibre router and register with it.  I'd create a separate site for the remote AP, and one for anything Omada-ish you have behind the Fibe connection.  I've done this and it worked great, no single point of failure behind the Starlink box, and only 1 physical port needed, and you can continue to use the Starlink Wifi if you desire.

  @Brian312 

Pretty sure you can only use your Bell b1 PPPoE credentials on a Bell access network :). This means you cannot use your login credentials and a router to get a public IP at the trailer via Elon's network.

If all you want to do is remote monitor and manage the AP at the trailer, the easiest thing to do is install an OC200 inside your homenetwork and forward the Omada control ports to it and enable cloud access (I don't expose the Web ports, but use TPlink's cloud connector instead).  The reason for this is that the OC200 provides the necessary packet relay to defeat the CGNAT on Starlink, either locally, or via the included cloud access to the OC200. Then on the trailer AP, configure the AP with your home's NOIP alias, fire it up, adopt it via the controller remotely (via the tplink cloud), and you are good to go.

One very useful side benefit of the remote controller managing the AP, is you notifications when it stops responding...which means you will know if and when the power has gone out, and if it has come back on by the status alerts you'll get via the Omada app.  For me, the value of this info more than covered the one time C$120 outlay for the controller, and if that's still too much, I posted earlier about how to make a C$55 Raspberry Pi-clone based controller that was at least as good as the OC200.

  @Brian312 

See here for the ports, needed, but I think you only need 29810, 29814-816 for v5 controllers forwarded across the router.

https://www.tp-link.com/ca/support/faq/3281/

  @Brian312 

Now that's a good question!  I haven't tried AP meshing with a remote controller yet, but, I'm thinking it should still work...otherwise the TPlink 'Cloud Controller' would never be able to support meshing between APs (which would be a huge negative).  You can always buy the second AP and try it once you get the first one up and running.

@Clive_A Is there more detail on controller support for meshing and/or features like fast roaming, when the controller is remote from the AP/user subnets?

Hi @d0ugmac1，

I'm afraid the Mesh and Fast Roaming couldn't work in different network/subnet.