@Fae 

I recorded packets using Wireshark from the Radius Server (NPS), and I can only see that the source for authentication is EAP (IP 192.168.0.127), not the Omada controller (IP 192.168.0.1).

It can be confirmed that the Radius Proxy feature is not enabled. Could you provide an overall configuration guide to help identify the problem areas? Thank you.

  @Fae 

Also tested using Freeradius for verification

You can see that the verification client IPs are all EAP IPs and not from the controller.

  @Timothy-Hsiao My customer is also facing this issue, was your issue solved and how?

  @Timothy-Hsiao same here, packets coming from EAP and not the controller. Did you figure anything out?

Also, to note, https://www.tp-link.com/sg/support/faq/2678/ also mentions in the middle of the page:

"Note: The Radius Client role is transferred from EAP to Omada Controller since Controller 3.1.4."

Tagging some TP-Link staff for help: @Vincent-TP 

Thank you in advance!

It looks like even with Radius Proxy enabled on the controller, the authentication requests are still being sent directly from the EAPs, not the controller. This usually means the proxy feature isn’t actually active.

Make sure you're using Omada Controller v5.12 or higher (and not just the OC200 firmware) — earlier versions don’t enforce the proxy setting even if configured. Also double-check that your EAPs are adopted and managed via Controller mode, not standalone. The Radius Proxy only works in full SDN controller deployments.

If all that checks out and it still fails, try restarting both the controller and EAPs after enabling Radius Proxy. It may take a full refresh to start routing properly.

By the way, when handling proxy-based architectures I’ve also used a good proxy service from lightningproxies for managing and testing connections. Their data center proxies have been reliable and easy to use alongside systems like Omada when I needed consistent IP routing and minimal setup.