"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
This thread has been locked for further replies. You can start a new thread to share your ideas or ask questions.Setting the X-Forwarded-Proto header causes the Omada Controller to 404.
Using controller 5.3.1 on Docker (https://github.com/mbentley/docker-omada-controller).
With header:
curl -kv https://localhost:8043/<id>/login -s -o /dev/null -H 'X-Forwarded-Proto: https' * Trying ::1:8043... * Connected to localhost (::1) port 8043 (#0) <snip> > GET /<id>/login HTTP/1.1 > Host: localhost:8043 > User-Agent: curl/7.74.0 > Accept: */* > X-Forwarded-Proto: https > < HTTP/1.1 404 < X-Frame-Options: SAMEORIGIN < X-Content-Type-Options: nosniff < Strict-Transport-Security: max-age=31536000; includeSubDomains < Referrer-Policy: strict-origin-when-cross-origin < Content-Length: 0 < Date: Thu, 02 Jun 2022 23:41:07 GMT < * Connection #0 to host localhost left intact ============================================================================= Without header:
curl -kv https://localhost:8043/<id>/login -s -o /dev/null
<snip>
> GET /<id>/login HTTP/1.1
> Host: localhost:8043
> User-Agent: curl/7.74.0
> Accept: */*
>
< HTTP/1.1 200
< X-Frame-Options: SAMEORIGIN
< X-Content-Type-Options: nosniff
< Strict-Transport-Security: max-age=31536000; includeSubDomains
< Referrer-Policy: strict-origin-when-cross-origin
< Content-Type: text/html;charset=utf-8
< Content-Language: en-US
< Transfer-Encoding: chunked
< Date: Thu, 02 Jun 2022 23:42:35 GMT
<
{ [3658 bytes data]
* Connection #0 to host localhost left intact- Copy Link
- Subscribe
- Bookmark
- Report Inappropriate Content
Dear @vsz,
vsz wrote
@Fae I'm also on v5.5.6 where this is still an issue. Was there an update on this ticket?
Regarding the ticket TKID220629866, the cause of the 404 problem is that the "X-Forwarded-Proto" uses port 443 while the exposed port of the Controller is 8043 by default. To run a reverse proxy and the Omada Controller on the same host, it requires both use port 443, while the Omada Software Controller (v5.1 - v5.3) didn't allow to set port 443 as the HTTPS management port.
To fix the issue, Omada Controller v5.5.6 has supported the use of port 443 as the HTTPS management port. If you suffer from the same issue, please go to Settings -> Controller -> Access Config, change the HTTPS Port for Controller Management to 443 for checking.
- Copy Link
- Report Inappropriate Content
@Fae Hi,
Can you help submit a ticket for this?
This prevents the controller from being used behind a reverse proxy, which is a very common issue for many people.
- Copy Link
- Report Inappropriate Content
Dear @linkerman,
linkerman wrote
Can you help submit a ticket for this?
This prevents the controller from being used behind a reverse proxy, which is a very common issue for many people.
Sorry for my delayed response. I've created a support ticket via your registered email address, and escalated it to our support engineer to look into the issue. The ticket ID is TKID220629866, please check your email box and ensure the support email is well received. Thanks!
- Copy Link
- Report Inappropriate Content
- Copy Link
- Report Inappropriate Content
I have encountered this bug, can't get reverse proxy running right, did almost everything in 2 days before I found this issue. This is what I have in traefik to get it working: https://github.com/budimanjojo/home-cluster/blob/ab3d17f8a3607693633f04d8838d886ed6ed5331/cluster/apps/default/omada/controller/ingress-traefikCRD.yaml#L35
Really hope TP Link can fix this because this is really frustrating.
- Copy Link
- Report Inappropriate Content
EDIT
- Copy Link
- Report Inappropriate Content
@btx that's the version I used all this time.
- Copy Link
- Report Inappropriate Content
@Fae I'm also on v5.5.6 where this is still an issue. Was there an update on this ticket?
- Copy Link
- Report Inappropriate Content
Dear @vsz,
vsz wrote
@Fae I'm also on v5.5.6 where this is still an issue. Was there an update on this ticket?
Regarding the ticket TKID220629866, the cause of the 404 problem is that the "X-Forwarded-Proto" uses port 443 while the exposed port of the Controller is 8043 by default. To run a reverse proxy and the Omada Controller on the same host, it requires both use port 443, while the Omada Software Controller (v5.1 - v5.3) didn't allow to set port 443 as the HTTPS management port.
To fix the issue, Omada Controller v5.5.6 has supported the use of port 443 as the HTTPS management port. If you suffer from the same issue, please go to Settings -> Controller -> Access Config, change the HTTPS Port for Controller Management to 443 for checking.
- Copy Link
- Report Inappropriate Content
@Fae Thank you.
I managed to get this to work by setting, however it also required some extra configuration (particularly on kubernetes/docker) in order to allow the controller to bind to 443 as that is a privileged port: https://github.com/mbentley/docker-omada-controller#unprivileged-ports
I note that pretty much any other web application is able to function with a reverse proxy remapping the port without any problems, so matching the ports being required was quite unexpected for me.
Best
- Copy Link
- Report Inappropriate Content
Fae wrote
Regarding the ticket TKID220629866, the cause of the 404 problem is that the "X-Forwarded-Proto" uses port 443 while the exposed port of the Controller is 8043 by default. To run a reverse proxy and the Omada Controller on the same host, it requires both use port 443...
The "X-Forwarded-Proto" header does not indicate or use any port - you are mixing it up with the "X-Forwarded-Port" header which does not lead here to any issues with the omada controller. @Fae is this issue going to be fixed soon?
Using port 443 on the controller is also not possible, because it looks like devices connect to the HTTPS port of the controller to download new firmware using directly the IP address without proper "Host" header, which requires the port to be exposed directly on the IP (does conflict with the reverse proxy itself on single IP) or being setup as a default server in the reverse proxy (also a nope here, 404 is preferred).
Why does it have to be such a hassle to setup an enterprise application instead of just following standards and fixing the software?
- Copy Link
- Report Inappropriate Content
Information
Helpful: 3
Views: 1663
Replies: 10
Voters 1
