github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-07-16 14:47:04 -05:00
Code Issues 1.6k Packages Projects Releases 79 Wiki Activity

[GH-ISSUE #2952] Private HTTP proxy appears to not follow redirects #13085

New Issue
Closed
opened 2026-05-13 18:37:57 -05:00 by GiteaMirror · 22 comments
GiteaMirror commented 2026-05-13 18:37:57 -05:00
Owner
Copy Link

Originally created by @Vyerni on GitHub (May 1, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2952

Describe the Bug

I'm currently trying to set up a private http proxy to be able to access my servers IDRAC console, something I definitely do not want exposed in any way.

I have it set up with the site, HTTP, using HTTPS scheme, to the IP (172.23.17.14) and port 443. I also have Enable SSL ticked.

When I browse to the domain without a client connection. I get a placeholder page. - Perfect
When I browse to the domain with one "https://idrac.domain", my browser url becomes "172.23.17.14/start.html" and it errors with "This site can't be reached. ERR_CONNECTION_REFUSED"
When I browse to "https://idrac.domain/login.html" I'm able to access the web page as required.

I'm currently on the latest Pangolin EE and Newt. I believe this was working on 1.18-rc.0 and newt 1.12-rc

Environment

  • OS Type & Version: (e.g., Ubuntu 22.04): Docker on TrueNAS
  • Pangolin Version: 1.18.1
  • Gerbil Version: 1.3.1
  • Traefik Version: 3.6
  • Newt Version: 1.12.1
  • Olm Version: (if applicable)

To Reproduce

.

Expected Behavior

.

Originally created by @Vyerni on GitHub (May 1, 2026). Original GitHub issue: https://github.com/fosrl/pangolin/issues/2952 ### Describe the Bug I'm currently trying to set up a private http proxy to be able to access my servers IDRAC console, something I definitely do not want exposed in any way. I have it set up with the site, HTTP, using HTTPS scheme, to the IP (172.23.17.14) and port 443. I also have Enable SSL ticked. When I browse to the domain without a client connection. I get a placeholder page. - Perfect When I browse to the domain with one "https://idrac.domain", my browser url becomes "172.23.17.14/start.html" and it errors with "This site can't be reached. ERR_CONNECTION_REFUSED" When I browse to "https://idrac.domain/login.html" I'm able to access the web page as required. I'm currently on the latest Pangolin EE and Newt. I *believe* this was working on 1.18-rc.0 and newt 1.12-rc ### Environment - OS Type & Version: (e.g., Ubuntu 22.04): Docker on TrueNAS - Pangolin Version: 1.18.1 - Gerbil Version: 1.3.1 - Traefik Version: 3.6 - Newt Version: 1.12.1 - Olm Version: (if applicable) ### To Reproduce . ### Expected Behavior .
GiteaMirror commented 2026-05-13 18:37:57 -05:00
Author
Owner
Copy Link

@AstralDestiny commented on GitHub (May 3, 2026):

Responded in discord.

<!-- gh-comment-id:4365803628 --> @AstralDestiny commented on GitHub (May 3, 2026): Responded in discord.
GiteaMirror commented 2026-05-13 18:37:58 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 5, 2026):

Ironically appears to be a problem with the only 2 services I originally tried to setup with private resources, IDRAC and my TrueNAS GUI

Will work out an alternative for these 2.

Thanks for the help.

<!-- gh-comment-id:4378633860 --> @Vyerni commented on GitHub (May 5, 2026): Ironically appears to be a problem with the only 2 services I originally tried to setup with private resources, IDRAC and my TrueNAS GUI Will work out an alternative for these 2. Thanks for the help.
GiteaMirror commented 2026-05-13 18:37:58 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (May 5, 2026):

What was worked out? Do we need to handle redirects in the newt proxy? I
can make sure that occurs if its needed to make these services work!

<!-- gh-comment-id:4381329942 --> @oschwartz10612 commented on GitHub (May 5, 2026): What was worked out? Do we need to handle redirects in the newt proxy? I can make sure that occurs if its needed to make these services work!
GiteaMirror commented 2026-05-13 18:37:58 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 5, 2026):

I truthfully don't fully understand. Hopefually @AstralDestiny can explain it a little better.

But in the case of the IDRAC, it has a hardcoded href on the page, apparently causing problems.

Apologies I can't help explain it on a technical level.

<!-- gh-comment-id:4382685339 --> @Vyerni commented on GitHub (May 5, 2026): I truthfully don't fully understand. Hopefually @AstralDestiny can explain it a little better. But in the case of the IDRAC, it has a hardcoded href on the page, apparently causing problems. Apologies I can't help explain it on a technical level.
GiteaMirror commented 2026-05-13 18:37:59 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

I've attempted to try and get it working to my TrueNAS GUI, and it's a similar thing.

server.vpn.domain is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct)

But then if I do server.vpn.domain/ui/dashboard it works

Edit:
Newt 1.12.3
Pangolin 1.18.3-EE
Gerbil 1.4.0

<!-- gh-comment-id:4405247478 --> @Vyerni commented on GitHub (May 8, 2026): I've attempted to try and get it working to my TrueNAS GUI, and it's a similar thing. `server.vpn.domain` is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct) But then if I do `server.vpn.domain/ui/dashboard` it works Edit: Newt 1.12.3 Pangolin 1.18.3-EE Gerbil 1.4.0
GiteaMirror commented 2026-05-13 18:37:59 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

I've attempted to try and get it working to my TrueNAS GUI, and it's a similar thing.

server.vpn.domain is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct)

But then if I do server.vpn.domain/ui/dashboard it works

But if you curl that resource from where Newt is situated you get a redirect? curl http://172.23.17.5:4430/ui as Newt is simply proxying what the resource is responding

<!-- gh-comment-id:4405274390 --> @LaurenceJJones commented on GitHub (May 8, 2026): > I've attempted to try and get it working to my TrueNAS GUI, and it's a similar thing. > > `server.vpn.domain` is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct) > > But then if I do `server.vpn.domain/ui/dashboard` it works But if you curl that resource from where Newt is situated you get a redirect? `curl http://172.23.17.5:4430/ui` as Newt is simply proxying what the resource is responding
GiteaMirror commented 2026-05-13 18:38:00 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

Pretty hard to do as I'm testing the private connection via my phone.

Not sure if it's a valid test, but locally on my PC that is on the same LAN as the TrueNAS and newt, I get this:

PS C:\Users\user> curl.exe -vk https://server.domain:4430
* Host server.domain:4430 was resolved.
* IPv6: (none)
* IPv4: 172.23.17.5
*   Trying 172.23.17.5:4430...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Established connection to server.domain (172.23.17.5 port 4430) from 172.23.17.3 port 6191
* using HTTP/1.x
> GET / HTTP/1.1
> Host: server.domain:4430
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 302 Moved Temporarily
< Server: nginx
< Date: Fri, 08 May 2026 09:23:52 GMT
< Content-Type: text/html
< Content-Length: 138
< Connection: keep-alive
< Location: https://server.domain:4430/ui/
< Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()
< Referrer-Policy: strict-origin
< X-Frame-Options: SAMEORIGIN
<
<html>
<head><title>302 Found</title></head>
<body>
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host server.domain:4430 left intact


PS C:\Users\user> curl.exe  -vk https://172.23.17.5:4430/ui
*   Trying 172.23.17.5:4430...
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: curl offers http/1.1
* ALPN: server accepted http/1.1
* Established connection to 172.23.17.5 (172.23.17.5 port 4430) from 172.23.17.3 port 58021
* using HTTP/1.x
> GET /ui HTTP/1.1
> Host: 172.23.17.5:4430
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
* schannel: remote party requests renegotiation
* schannel: renegotiating SSL/TLS connection
* schannel: SSL/TLS connection renegotiated
< HTTP/1.1 301 Moved Permanently
< Server: nginx
< Date: Fri, 08 May 2026 09:28:51 GMT
< Content-Type: text/html
< Content-Length: 162
< Location: https://172.23.17.5:4430/ui/
< Connection: keep-alive
< Cache-Control: must-revalidate
< Etag: TrueNAS-26.0.0-BETA.1
< Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=()
< Referrer-Policy: strict-origin
< X-Frame-Options: SAMEORIGIN
<
<html>
<head><title>301 Moved Permanently</title></head>
<body>
<center><h1>301 Moved Permanently</h1></center>
<hr><center>nginx</center>
</body>
</html>
* Connection #0 to host 172.23.17.5:4430 left intact
<!-- gh-comment-id:4405295790 --> @Vyerni commented on GitHub (May 8, 2026): Pretty hard to do as I'm testing the private connection via my phone. Not sure if it's a valid test, but locally on my PC that is on the same LAN as the TrueNAS and newt, I get this: ``` PS C:\Users\user> curl.exe -vk https://server.domain:4430 * Host server.domain:4430 was resolved. * IPv6: (none) * IPv4: 172.23.17.5 * Trying 172.23.17.5:4430... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Established connection to server.domain (172.23.17.5 port 4430) from 172.23.17.3 port 6191 * using HTTP/1.x > GET / HTTP/1.1 > Host: server.domain:4430 > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated < HTTP/1.1 302 Moved Temporarily < Server: nginx < Date: Fri, 08 May 2026 09:23:52 GMT < Content-Type: text/html < Content-Length: 138 < Connection: keep-alive < Location: https://server.domain:4430/ui/ < Strict-Transport-Security: max-age=63072000; includeSubDomains; preload < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=() < Referrer-Policy: strict-origin < X-Frame-Options: SAMEORIGIN < <html> <head><title>302 Found</title></head> <body> <center><h1>302 Found</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host server.domain:4430 left intact PS C:\Users\user> curl.exe -vk https://172.23.17.5:4430/ui * Trying 172.23.17.5:4430... * schannel: disabled automatic use of client certificate * schannel: using IP address, SNI is not supported by OS. * ALPN: curl offers http/1.1 * ALPN: server accepted http/1.1 * Established connection to 172.23.17.5 (172.23.17.5 port 4430) from 172.23.17.3 port 58021 * using HTTP/1.x > GET /ui HTTP/1.1 > Host: 172.23.17.5:4430 > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated * schannel: remote party requests renegotiation * schannel: renegotiating SSL/TLS connection * schannel: SSL/TLS connection renegotiated < HTTP/1.1 301 Moved Permanently < Server: nginx < Date: Fri, 08 May 2026 09:28:51 GMT < Content-Type: text/html < Content-Length: 162 < Location: https://172.23.17.5:4430/ui/ < Connection: keep-alive < Cache-Control: must-revalidate < Etag: TrueNAS-26.0.0-BETA.1 < Strict-Transport-Security: max-age=63072000; includeSubDomains; preload < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < Permissions-Policy: geolocation=(),midi=(),sync-xhr=(),microphone=(),camera=(),magnetometer=(),gyroscope=(),fullscreen=(self),payment=() < Referrer-Policy: strict-origin < X-Frame-Options: SAMEORIGIN < <html> <head><title>301 Moved Permanently</title></head> <body> <center><h1>301 Moved Permanently</h1></center> <hr><center>nginx</center> </body> </html> * Connection #0 to host 172.23.17.5:4430 left intact
GiteaMirror commented 2026-05-13 18:38:00 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

Apologies its https try that also that redirect is just promoting to https

You can pass -L to curl to follow the redirect chain

<!-- gh-comment-id:4405304381 --> @LaurenceJJones commented on GitHub (May 8, 2026): Apologies its https try that also that redirect is just promoting to https You can pass `-L` to curl to follow the redirect chain
GiteaMirror commented 2026-05-13 18:38:00 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

Updated earlier post with both commands.

If I browse in an incognito window to https://172.23.17.5:4430 it redirects me to https://172.23.17.5:4430/ui/signin

Edit:

I didn't see your edit when running the previous commands. Passing -L gives me a much larger output, which, I'm going to assuming is the correct result

<!-- gh-comment-id:4405324849 --> @Vyerni commented on GitHub (May 8, 2026): Updated earlier post with both commands. If I browse in an incognito window to ``https://172.23.17.5:4430`` it redirects me to ``https://172.23.17.5:4430/ui/signin`` Edit: I didn't see your edit when running the previous commands. Passing ``-L`` gives me a much larger output, which, I'm going to assuming is the correct result
GiteaMirror commented 2026-05-13 18:38:01 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

Im going to see if I can replicate it, but my theory is since we dont pass a Host header (we pass X-Forwarded-Host) the location being sent down over the private path is the IP address instead of the location being written as the private alias, so your connection refused might be because the redirect is converting to the ip address.

as by this

server.vpn.domain is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct)

Question do you know if truenas or the other application has a way to set trusted proxies as typically when this is configured the application should prefer X-Forwarded-Host instead of Host.

<!-- gh-comment-id:4405814941 --> @LaurenceJJones commented on GitHub (May 8, 2026): Im going to see if I can replicate it, but my theory is since we dont pass a Host header (we pass `X-Forwarded-Host`) the location being sent down over the private path is the IP address instead of the location being written as the private alias, so your connection refused might be because the redirect is converting to the ip address. as by this ``` server.vpn.domain is what I'm trying to do via VPN. And it redirects to 172.23.17.5:4430/ui with ERR_CONNECTION_REFUSED. (My GUI is served on 4430, so that's correct) ``` Question do you know if truenas or the other application has a way to set trusted proxies as typically when this is configured the application should prefer `X-Forwarded-Host` instead of `Host`.
GiteaMirror commented 2026-05-13 18:38:01 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

I don't believe there's an option for it in either TrueNAS or, Dell IDRAC. At least, I've not seen anything like "trusted proxies", etc.

<!-- gh-comment-id:4405870033 --> @Vyerni commented on GitHub (May 8, 2026): I don't believe there's an option for it in either TrueNAS or, Dell IDRAC. At least, I've not seen anything like "trusted proxies", etc.
GiteaMirror commented 2026-05-13 18:38:01 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

Okay I got enough context to replicate and report back to @oschwartz10612 plus got a "fix" but need some more coffee before I am confident it doesnt introduce regressions.

<!-- gh-comment-id:4406093410 --> @LaurenceJJones commented on GitHub (May 8, 2026): Okay I got enough context to replicate and report back to @oschwartz10612 plus got a "fix" but need some more coffee before I am confident it doesnt introduce regressions.
GiteaMirror commented 2026-05-13 18:38:02 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

Okay I see the regression from 1.12.2 onwards for @oschwartz10612

Before our proxy used to use

proxy := httputil.NewSingleHostReverseProxy(targetURL)

but now we do

	proxy := &httputil.ReverseProxy{
		Rewrite: func(pr *httputil.ProxyRequest) {
			pr.SetURL(targetURL)
			// SetXForwarded sets X-Forwarded-For from the inbound request's
			// RemoteAddr (the WireGuard/netstack client address), along with
			// X-Forwarded-Host and X-Forwarded-Proto. Using Rewrite instead of
			// Director means the proxy does not append its own automatic
			// X-Forwarded-For entry, so the header is set exactly once.
			pr.SetXForwarded()
		},

as stated in the go docs

SetURL rewrites the outbound Host header to match the target's host. To preserve the inbound request's Host header (the default behavior of NewSingleHostReverseProxy)

in short the host header is being rewritten from example.vpn.domain to 172.... (in your example) then downstream applications that use full redirect logic are returning that.

the simple fix would be to follow the go docs

rewriteFunc := func(r *httputil.ProxyRequest) {
    r.SetURL(url)
    r.Out.Host = r.In.Host // add this line to preserve the host header from the incoming request
}

I havent had time to test if it fixes it, but in theory that should be it. I am surprised there isnt more people hitting this issue in fact unless public resource through traefik are getting some sort of traefik magic 🤷🏻

<!-- gh-comment-id:4406410468 --> @LaurenceJJones commented on GitHub (May 8, 2026): Okay I see the regression from `1.12.2` onwards for @oschwartz10612 Before our proxy used to use ```go proxy := httputil.NewSingleHostReverseProxy(targetURL) ``` but now we do ```go proxy := &httputil.ReverseProxy{ Rewrite: func(pr *httputil.ProxyRequest) { pr.SetURL(targetURL) // SetXForwarded sets X-Forwarded-For from the inbound request's // RemoteAddr (the WireGuard/netstack client address), along with // X-Forwarded-Host and X-Forwarded-Proto. Using Rewrite instead of // Director means the proxy does not append its own automatic // X-Forwarded-For entry, so the header is set exactly once. pr.SetXForwarded() }, ``` as stated in the go docs ` SetURL rewrites the outbound Host header to match the target's host. To preserve the inbound request's Host header (the default behavior of NewSingleHostReverseProxy) ` in short the host header is being rewritten from `example.vpn.domain` to `172....` (in your example) then downstream applications that use full redirect logic are returning that. the simple fix would be to follow the go docs ```go rewriteFunc := func(r *httputil.ProxyRequest) { r.SetURL(url) r.Out.Host = r.In.Host // add this line to preserve the host header from the incoming request } ``` I havent had time to test if it fixes it, but in theory that should be it. I am surprised there isnt more people hitting this issue in fact unless public resource through traefik are getting some sort of traefik magic 🤷🏻
GiteaMirror commented 2026-05-13 18:38:02 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

TrueNAS is now accessible with newt 1.12.5, but the IDRAC is still not.

Browsing to idrac.vpn.domain leads me to 172.23.17.14/start.html and browser saying ERR_CONNECTION_REFUSED, but if I browse to idrac.vpn.domain/start.html or idrac.vpn.domain/login.html it loads the IDRAC page.

* Host idrac.domain:443 was resolved.
* IPv6: (none)
* IPv4: 172.23.17.14
*   Trying 172.23.17.14:443...
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
* Established connection to idrac.domain (172.23.17.14 port 443) from 172.23.17.3 port 18445
* using HTTP/1.x
> GET / HTTP/1.1
> Host: idrac.domain
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 302 Moved Temporarily
< Strict-Transport-Security: max-age=63072000
< Vary: Accept-Encoding
< Keep-Alive: timeout=60, max=199
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/x-gzip
< Location: https://idrac.domain/start.html
< Date: Fri, 08 May 2026 19:56:47 GMT
< ETag: Sat May 09 05:56:48 2026 AEST
< Content-Length: 218
< Last-Modified: Fri, 29 Mar 2024 09:23:50 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
* Ignoring the response-body
* setting size while ignoring
<
* Connection #0 to host idrac.domain:443 left intact
* Issue another request to this URL: 'https://idrac.domain/start.html'
* Reusing existing https: connection with host idrac.domain
> GET /start.html HTTP/1.1
> Host: idrac.domain
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Strict-Transport-Security: max-age=63072000
< Vary: Accept-Encoding
< Keep-Alive: timeout=60, max=198
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/html
< Date: Fri, 08 May 2026 19:56:47 GMT
< Cache-Control: no-cache
< Content-Length: 223
< Connection: Keep-Alive
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<head>
    <title>Not Found</title>
    <link rel="shortcut icon" href="data:image/x-icon;," type="image/x-icon">
</head>
<body>
<h2>Access Error: 404 -- Not Found</h2>
<pre></pre>
</body>
</html>
* Connection #0 to host idrac.domain:443 left intact
PS C:\Users\user>
PS C:\Users\user>
PS C:\Users\user>
PS C:\Users\user>
PS C:\Users\user> curl.exe  -vkL https://172.23.17.14
*   Trying 172.23.17.14:443...
* schannel: disabled automatic use of client certificate
* schannel: using IP address, SNI is not supported by OS.
* ALPN: curl offers http/1.1
* ALPN: server did not agree on a protocol. Uses default.
* Established connection to 172.23.17.14 (172.23.17.14 port 443) from 172.23.17.3 port 18458
* using HTTP/1.x
> GET / HTTP/1.1
> Host: 172.23.17.14
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 302 Moved Temporarily
< Strict-Transport-Security: max-age=63072000
< Vary: Accept-Encoding
< Keep-Alive: timeout=60, max=199
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/x-gzip
< Location: https://172.23.17.14/start.html
< Date: Fri, 08 May 2026 19:57:49 GMT
< ETag: Sat May 09 05:57:49 2026 AEST
< Content-Length: 201
< Last-Modified: Fri, 29 Mar 2024 09:23:50 GMT
< Connection: Keep-Alive
< Accept-Ranges: bytes
* Ignoring the response-body
* setting size while ignoring
<
* Connection #0 to host 172.23.17.14:443 left intact
* Issue another request to this URL: 'https://172.23.17.14/start.html'
* Reusing existing https: connection with host 172.23.17.14
> GET /start.html HTTP/1.1
> Host: 172.23.17.14
> User-Agent: curl/8.19.0
> Accept: */*
>
* Request completely sent off
< HTTP/1.1 404 Not Found
< Strict-Transport-Security: max-age=63072000
< Vary: Accept-Encoding
< Keep-Alive: timeout=60, max=198
< X-Frame-Options: SAMEORIGIN
< Content-Type: text/html
< Date: Fri, 08 May 2026 19:57:49 GMT
< Cache-Control: no-cache
< Content-Length: 223
< Connection: Keep-Alive
< Accept-Ranges: bytes
<
<!DOCTYPE html>
<head>
    <title>Not Found</title>
    <link rel="shortcut icon" href="data:image/x-icon;," type="image/x-icon">
</head>
<body>
<h2>Access Error: 404 -- Not Found</h2>
<pre></pre>
</body>
</html>
* Connection #0 to host 172.23.17.14:443 left intact
<!-- gh-comment-id:4409465367 --> @Vyerni commented on GitHub (May 8, 2026): TrueNAS is now accessible with newt 1.12.5, but the IDRAC is still not. Browsing to ``idrac.vpn.domain`` leads me to ``172.23.17.14/start.html`` and browser saying ERR_CONNECTION_REFUSED, but if I browse to ``idrac.vpn.domain/start.html`` or ``idrac.vpn.domain/login.html`` it loads the IDRAC page. ```PS C:\Users\user> curl.exe -vkL https://idrac.domain * Host idrac.domain:443 was resolved. * IPv6: (none) * IPv4: 172.23.17.14 * Trying 172.23.17.14:443... * schannel: disabled automatic use of client certificate * ALPN: curl offers http/1.1 * ALPN: server did not agree on a protocol. Uses default. * Established connection to idrac.domain (172.23.17.14 port 443) from 172.23.17.3 port 18445 * using HTTP/1.x > GET / HTTP/1.1 > Host: idrac.domain > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 Moved Temporarily < Strict-Transport-Security: max-age=63072000 < Vary: Accept-Encoding < Keep-Alive: timeout=60, max=199 < X-Frame-Options: SAMEORIGIN < Content-Type: application/x-gzip < Location: https://idrac.domain/start.html < Date: Fri, 08 May 2026 19:56:47 GMT < ETag: Sat May 09 05:56:48 2026 AEST < Content-Length: 218 < Last-Modified: Fri, 29 Mar 2024 09:23:50 GMT < Connection: Keep-Alive < Accept-Ranges: bytes * Ignoring the response-body * setting size while ignoring < * Connection #0 to host idrac.domain:443 left intact * Issue another request to this URL: 'https://idrac.domain/start.html' * Reusing existing https: connection with host idrac.domain > GET /start.html HTTP/1.1 > Host: idrac.domain > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off < HTTP/1.1 404 Not Found < Strict-Transport-Security: max-age=63072000 < Vary: Accept-Encoding < Keep-Alive: timeout=60, max=198 < X-Frame-Options: SAMEORIGIN < Content-Type: text/html < Date: Fri, 08 May 2026 19:56:47 GMT < Cache-Control: no-cache < Content-Length: 223 < Connection: Keep-Alive < Accept-Ranges: bytes < <!DOCTYPE html> <head> <title>Not Found</title> <link rel="shortcut icon" href="data:image/x-icon;," type="image/x-icon"> </head> <body> <h2>Access Error: 404 -- Not Found</h2> <pre></pre> </body> </html> * Connection #0 to host idrac.domain:443 left intact PS C:\Users\user> PS C:\Users\user> PS C:\Users\user> PS C:\Users\user> PS C:\Users\user> curl.exe -vkL https://172.23.17.14 * Trying 172.23.17.14:443... * schannel: disabled automatic use of client certificate * schannel: using IP address, SNI is not supported by OS. * ALPN: curl offers http/1.1 * ALPN: server did not agree on a protocol. Uses default. * Established connection to 172.23.17.14 (172.23.17.14 port 443) from 172.23.17.3 port 18458 * using HTTP/1.x > GET / HTTP/1.1 > Host: 172.23.17.14 > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off < HTTP/1.1 302 Moved Temporarily < Strict-Transport-Security: max-age=63072000 < Vary: Accept-Encoding < Keep-Alive: timeout=60, max=199 < X-Frame-Options: SAMEORIGIN < Content-Type: application/x-gzip < Location: https://172.23.17.14/start.html < Date: Fri, 08 May 2026 19:57:49 GMT < ETag: Sat May 09 05:57:49 2026 AEST < Content-Length: 201 < Last-Modified: Fri, 29 Mar 2024 09:23:50 GMT < Connection: Keep-Alive < Accept-Ranges: bytes * Ignoring the response-body * setting size while ignoring < * Connection #0 to host 172.23.17.14:443 left intact * Issue another request to this URL: 'https://172.23.17.14/start.html' * Reusing existing https: connection with host 172.23.17.14 > GET /start.html HTTP/1.1 > Host: 172.23.17.14 > User-Agent: curl/8.19.0 > Accept: */* > * Request completely sent off < HTTP/1.1 404 Not Found < Strict-Transport-Security: max-age=63072000 < Vary: Accept-Encoding < Keep-Alive: timeout=60, max=198 < X-Frame-Options: SAMEORIGIN < Content-Type: text/html < Date: Fri, 08 May 2026 19:57:49 GMT < Cache-Control: no-cache < Content-Length: 223 < Connection: Keep-Alive < Accept-Ranges: bytes < <!DOCTYPE html> <head> <title>Not Found</title> <link rel="shortcut icon" href="data:image/x-icon;," type="image/x-icon"> </head> <body> <h2>Access Error: 404 -- Not Found</h2> <pre></pre> </body> </html> * Connection #0 to host 172.23.17.14:443 left intact
GiteaMirror commented 2026-05-13 18:38:02 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

It says connection refused or 404 page not found, your curl output doesn't match what you wrote?

If it's not the right output we really need you to show or download the windows client to test as rather hard to not see debuggable info

<!-- gh-comment-id:4409761524 --> @LaurenceJJones commented on GitHub (May 8, 2026): It says connection refused or 404 page not found, your curl output doesn't match what you wrote? If it's not the right output we really need you to show or download the windows client to test as rather hard to not see debuggable info
GiteaMirror commented 2026-05-13 18:38:03 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

Curl.txt
pangolin-log-2026-05-09T070856_debug.txt

See the logs attached. These are run from my laptop with WIndows client.

First tried to browse to idrac.vpn.domain on the laptop, then attempted to run the curl commands attached, first to idrac.vpn.domain then the next to idrac.vpn.domain/start.html

<!-- gh-comment-id:4409898924 --> @Vyerni commented on GitHub (May 8, 2026): [Curl.txt](https://github.com/user-attachments/files/27539300/Curl.txt) [pangolin-log-2026-05-09T070856_debug.txt](https://github.com/user-attachments/files/27539299/pangolin-log-2026-05-09T070856_debug.txt) See the logs attached. These are run from my laptop with WIndows client. First tried to browse to ``idrac.vpn.domain`` on the laptop, then attempted to run the curl commands attached, first to ``idrac.vpn.domain`` then the next to ``idrac.vpn.domain/start.html``
GiteaMirror commented 2026-05-13 18:38:03 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

And when you previously without the VPN ran drac.domain is that the hostname on the LAN?

Reading up on idrac it seems it has lots of problems behind a reverse proxy, even dell recommend you only connect via the IP address only.

<!-- gh-comment-id:4409924242 --> @LaurenceJJones commented on GitHub (May 8, 2026): And when you previously without the VPN ran `drac.domain` is that the hostname on the LAN? Reading up on idrac it seems it has lots of problems behind a reverse proxy, even dell recommend you only connect via the IP address only.
GiteaMirror commented 2026-05-13 18:38:03 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

Yes.

idrac.domain is resolved from pfsense to 172.23.17.14 locally.

<!-- gh-comment-id:4409935979 --> @Vyerni commented on GitHub (May 8, 2026): Yes. ``idrac.domain`` is resolved from pfsense to 172.23.17.14 locally.
GiteaMirror commented 2026-05-13 18:38:04 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

Yeah it seems idrac is not designed to be behind a reverse proxy, searching it seems to show a lot of people have issues. It seems idrac only knows how to return redirects for its own hostname on LAN or defaults to IP address.

So unless you can dig into their docs, there isn't much more we can do.

<!-- gh-comment-id:4409945966 --> @LaurenceJJones commented on GitHub (May 8, 2026): Yeah it seems idrac is not designed to be behind a reverse proxy, searching it seems to show a lot of people have issues. It seems idrac only knows how to return redirects for its own hostname on LAN or defaults to IP address. So unless you can dig into their docs, there isn't much more we can do.
GiteaMirror commented 2026-05-13 18:38:04 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

That's fine, and makes sense given what @AstralDestiny found that there is a href hardcoded in.

Just wanted to provide all the info to make sure it was covered. Appreciate the looking into it.

<!-- gh-comment-id:4409955851 --> @Vyerni commented on GitHub (May 8, 2026): That's fine, and makes sense given what @AstralDestiny found that there is a href hardcoded in. Just wanted to provide all the info to make sure it was covered. Appreciate the looking into it.
GiteaMirror commented 2026-05-13 18:38:04 -05:00
Author
Owner
Copy Link

@LaurenceJJones commented on GitHub (May 8, 2026):

To resolve the redirect loop or refusal, you must tell the iDRAC to allow the specific FQDN or disable the check entirely.Option 1: Disable Host Header Check (Easiest)If your environment allows it, you can disable this security check using SSH and RACADM:bashracadm set idrac.webserver.HostHeaderCheck 0
Use code with caution.Option 2: Add the FQDN to the Allow-listIf you prefer to keep the security feature active, add the specific hostname the user is typing into the ManualDNSEntry field:
racadm set idrac.webserver.ManualDNSEntry https://domain.com

Just what I found if it helps

<!-- gh-comment-id:4409966838 --> @LaurenceJJones commented on GitHub (May 8, 2026): To resolve the redirect loop or refusal, you must tell the iDRAC to allow the specific FQDN or disable the check entirely.Option 1: Disable Host Header Check (Easiest)If your environment allows it, you can disable this security check using SSH and RACADM:bashracadm set idrac.webserver.HostHeaderCheck 0 Use code with caution.Option 2: Add the FQDN to the Allow-listIf you prefer to keep the security feature active, add the specific hostname the user is typing into the ManualDNSEntry field: racadm set idrac.webserver.ManualDNSEntry https://domain.com Just what I found if it helps
GiteaMirror commented 2026-05-13 18:38:04 -05:00
Author
Owner
Copy Link

@Vyerni commented on GitHub (May 8, 2026):

Set those, thanks.

But I have just gotten a small work around having noticed (again) that it changes to the LAN IP of 172.23.17.14.

I've since added an additional private resource of host at that IP address as well. So the proxy starts it, and then redirects me to the IP address, where the second resource then allows it. Seems to be working so far.

<!-- gh-comment-id:4410122216 --> @Vyerni commented on GitHub (May 8, 2026): Set those, thanks. But I have just gotten a small work around having noticed (again) that it changes to the LAN IP of 172.23.17.14. I've since added an additional private resource of host at that IP address as well. So the proxy starts it, and then redirects me to the IP address, where the second resource then allows it. Seems to be working so far.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
api
authentication
bug
config
dependencies
docker
documentation
enhancement
good first issue
help wanted
Improvement
Look Into
needs investigating
networking
new feature
non-critical bug
potential bug
pull-request
Mirrored from GitHub Pull Request
 question
reverse proxy
Security
stale
ui
wontfix
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/pangolin#13085
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?