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

"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.
"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-06-02 23:53:13 - last edited 2022-09-23 05:59:00
Hardware Version:
Firmware Version: 5.3.1

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
  3      
  3      
#1
Options
1 Accepted Solution
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404-Solution
2022-09-16 03:28:44 - last edited 2022-09-23 05:59:00

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.

>> Omada EAP Firmware Trial Available Here << *Try filtering posts on each forum by Label of [Early Access]*
Recommended Solution
  3  
  3  
#9
Options
10 Reply
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-06-17 02:11:10

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

  0  
  0  
#2
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-06-28 08:25:02

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!

>> Omada EAP Firmware Trial Available Here << *Try filtering posts on each forum by Label of [Early Access]*
  0  
  0  
#3
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-08-28 16:26:17
This is still a problem in 5.5. I just found this issue after debugging why the reverse proxy 404s with everything else configured correctly. I can't even fix this since X-Forwarded-Proto is a hardcoded header in ingress-nginx generated config. I'm sure lots of people have actually hit this issue but just chalked it down to not having ports/ssl correct. Do we know when this will be fixed?
  1  
  1  
#4
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-09-14 23:49:09

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.

  0  
  0  
#5
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-09-15 00:15:50 - last edited 2022-10-13 10:23:33

EDIT

  0  
  0  
#6
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-09-15 08:08:27

  @btx that's the version I used all this time.

  0  
  0  
#7
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-09-15 15:36:23

  @Fae I'm also on v5.5.6 where this is still an issue. Was there an update on this ticket?

  0  
  0  
#8
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404-Solution
2022-09-16 03:28:44 - last edited 2022-09-23 05:59:00

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.

>> Omada EAP Firmware Trial Available Here << *Try filtering posts on each forum by Label of [Early Access]*
Recommended Solution
  3  
  3  
#9
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2022-09-25 13:29:12

  @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

  1  
  1  
#10
Options
Re:"X-Forwarded-Proto" header causes Omada Controller v5 to return 404
2023-02-20 14:33:17 - last edited 2023-02-20 14:34:42

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?

  1  
  1  
#11
Options