mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-22 17:43:04 -05:00
[GH-ISSUE #452] [Feature Request] Allow customization of TLS server name (SNI) in ServersTransport #16442
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#16442
Reference in New Issue
Block a user
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?
Originally created by @4nx on GitHub (Apr 2, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/452
Background:
When using Pangolin in setups involving multiple reverse proxies (such as Traefik in a two-tier reverse proxy configuration), the server name used during the TLS handshake (SNI) to backend servers is currently not configurable and not set. As reported in Issue #207, this limitation causes TLS handshake failures because the backend reverse proxy does not receive the correct server name via SNI and thus cannot select the appropriate certificate.
Proposed Enhancement:
Implement an option within Pangolin's configuration to explicitly specify the TLS server name used during the connection establishment with backend services (ServersTransport). This would allow users to define a custom SNI value, ensuring proper TLS handshakes in scenarios involving multiple reverse proxies.
Benefits:
Related Issues:
Directly addresses problems discussed in Issue #207, specifically regarding TLS handshake errors caused by incorrect or missing SNI information.
@oschwartz10612 commented on GitHub (Apr 3, 2025):
Thanks for the feature request! I will leave this open instead of moving it to a discussion because I think it is a good first thing for someone to solve or we will do it soon!
@asychev commented on GitHub (Apr 10, 2025):
+1
I have split DNS setup and internal Reverse Proxy (Nginx Proxy Manager) requires SNI to work properly.
@franzfopa commented on GitHub (Apr 16, 2025):
SNI and ldap/oidc (to a lesser extent) are the two features that makes this project something I become a "full supporter" for - love the development speed and simplicity.
@mschirrmeister commented on GitHub (Apr 30, 2025):
Is https://github.com/fosrl/pangolin/pull/501 going to address this?
@miloschwartz commented on GitHub (May 1, 2025):
@mschirrmeister I believe so
@mschirrmeister commented on GitHub (May 2, 2025):
Technically I am sure it is addressing it. I guess my mind was more at the process, if this one here is just kept open until #501 is included in a GA release.
@mschirrmeister commented on GitHub (May 2, 2025):
Just tested
1.3.0and all looks good. Thank you very much.@4nx commented on GitHub (May 8, 2025):
I cannot confirm that the setting in the Advanced TLS Settings is working as expected. I observed that the request reaches the second reverse proxy with the host header still set to the service name that Pangolin is using externally.
For example, if Pangolin exposes a service as unifi.example.com, but the internal service expects requests for unifi.internal.com, then even after setting unifi.internal.com in the Advanced TLS Settings, the request is still forwarded with the host header unifi.example.com.
This causes routing issues on the downstream proxy, as it doesn't match the expected host.
@4nx commented on GitHub (May 8, 2025):
@mschirrmeister can you confirm that the setting on your setup is working as expected? Did you have a look on the requests which pangolin is doing?
@miloschwartz maybe you could reopen the feature request as it seems not working.
@achtnullzwei commented on GitHub (May 8, 2025):
I can confirm this is indeed not working as expected. Checked 1.3.0 and 1.3.1 (looking directly at the database)
Current behaviour:
...
Settings should not be coupled this way.
@miloschwartz @4nx
@miloschwartz commented on GitHub (May 9, 2025):
Thanks everyone this is bug I will get fixed here shortly. Hope to have a new release out soon.
@mschirrmeister commented on GitHub (May 9, 2025):
@4nx I did not run into this, because my internal services have the same name as on the external side.
Despite the still existing bug that @achtnullzwei described and based on what you described, you need to set your internal name in 2 places, not only the
TLS Server Name (SNI).The
Custom Host Headeris the field for all http level stuff and to find the correct virtual host.The TLS stuff is only important during the TLS handshake.
@4nx commented on GitHub (May 9, 2025):
@mschirrmeister ok with the same name it would work sure.
My problem is indeed first of all the SNI request because this fails first. I am not quite sure if you really need the custom host header as well but indeed it should be possible to configure both not only one at a time.
@miloschwartz thx for adressing this as a bug!