Replies: 16 comments
-
I do not use NPM so I don't have a way to simply test it and I don't see enough info here to know how to reproduce your configuration of the container & NPM. I know there are a number of people who use traefik and I haven't heard of anyone else having issues so it's hard to say if TP-Link changed or broke something about how reverse proxying is configured. But for me to help, I am going to need the equivalent of the |
Beta Was this translation helpful? Give feedback.
-
Here's the docker run command:
Here's the output of docker inspect:
During the image startup I can't see anything wrong except these two errors:
My NPM config is very simple I just forward 443 traffic from the domain to https://192.168.0.14:18043 with no other config like custom locations etc. This used to work and nothing has changed really other than me updating the docker image. And here are the controller settings in the UI. |
Beta Was this translation helpful? Give feedback.
-
Here's is the NPM config file as well
|
Beta Was this translation helpful? Give feedback.
-
Just a pointer, I use traefik, and ill let traefik handle ssl certs, and point my instance to omada http, without https redirect. This makes certs and everything work really nice. |
Beta Was this translation helpful? Give feedback.
-
Sorry for the delay in looking at the configs that you provided; I will try to take a look a bit later today. |
Beta Was this translation helpful? Give feedback.
-
There's a new beta firmware released. |
Beta Was this translation helpful? Give feedback.
-
@mbentley any update on this issue? I'm still having this problem on v5.15.6.7 |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
My settings in NPM are exactly like the ones one your screenshots. Weirdly though I'm not getting the same errors in the console. I'm getting the same errors on loading the page and on logon attempt. There seems to be an error with the password field in the form but I don't understand why that would be? |
Beta Was this translation helpful? Give feedback.
-
exact same log though shows up when accessing via the IP directly where logon works on that. So I guess nothing that points out to what the problem actually is. |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
That works and it's probably the best solution tbh and then I can let NPM handle all the cert stuff. Only question is whether this will break any device updating? I've had a recurring issue with a remote gateway that I've adopted, not updating it's software cause of IP and SSL issues. I think last time I was looking into this it was to do with the way the update is pulled from the controller after it was downloaded and was relevant to the internal IP vs external IP since this is a remote gateway. I think you were the one pointing out the issue in another old thread. |
Beta Was this translation helpful? Give feedback.
-
It's been a while since I've looked at that specific issue with how it works with the device updates - I honestly don't know or recall at the moment and would have to refer back to a previous thread about the update behavior, assuming none of that has changed in the app at this point. |
Beta Was this translation helpful? Give feedback.
-
Yeah so the updating issue I have which is slightly relevant with the reverse proxy usage is covered here: https://community.tp-link.com/en/business/forum/topic/598378 It's even more complicated when the device you managing is remote. Played a bit with it now again and managed to find a solution but it's far from ideal. For some reason for updating, gateways/switches require access to the Omada controller management port (18043). this essentially means that if you want to update a device you need to get it to bypass the reverse proxy. It's very messy with remote hosts because you basically need to expose port 10843 to the internet without a proxy in between. Just tested it and it works but not a great solution really. |
Beta Was this translation helpful? Give feedback.
-
I usually use Traefik, but have NPM running just for testing. I just added my controller to NPM to test it out. On the controller I have enabled Redirect HTTP to HTTPS, Auto Refresh Portal IP, HTTP redirect to HTTPS for Portal. Using these settings works perfect every time. So I would say NPM works fine on the latest version of the controller with the settings above. |
Beta Was this translation helpful? Give feedback.
-
Moved to a discussion since this isn't a technical issue related to the packaging of the container. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Controller Version
v5.14.32
Describe the Bug
This started happening after the latest update.
I have configured nginx proxy manager and can access through there via an internal only domain name.
This used to work fine but now it seems that I'm stuck in a login loop.
Login is successful when accessing directly via IP.
I have this running in docker in UNRAID.
only log I can see created on login attempt is the following.
Expected Behavior
Should be able to log in
Steps to Reproduce
access portal via URL
try to log in
How You're Launching the Container
Container Logs
MongoDB Logs
No response
Additional Context
No response
Beta Was this translation helpful? Give feedback.
All reactions