github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-22 09:32:36 -05:00
Code Issues 959 Packages Projects Releases 74 Wiki Activity

[GH-ISSUE #452] [Feature Request] Allow customization of TLS server name (SNI) in ServersTransport #3404

New Issue
Closed
opened 2026-04-20 07:20:57 -05:00 by GiteaMirror · 13 comments
GiteaMirror commented 2026-04-20 07:20:57 -05:00
Owner
Copy Link

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:

  • Resolves TLS handshake failures by ensuring correct SNI is passed to backend services.
  • Enables smoother integration with multi-layer reverse proxy setups.
  • Provides greater flexibility and robustness for advanced network configurations.

Related Issues:
Directly addresses problems discussed in Issue #207, specifically regarding TLS handshake errors caused by incorrect or missing SNI information.

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](https://github.com/fosrl/pangolin/issues/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:** * Resolves TLS handshake failures by ensuring correct SNI is passed to backend services. * Enables smoother integration with multi-layer reverse proxy setups. * Provides greater flexibility and robustness for advanced network configurations. **Related Issues:** Directly addresses problems discussed in [Issue #207](https://github.com/fosrl/pangolin/issues/207), specifically regarding TLS handshake errors caused by incorrect or missing SNI information.
GiteaMirror added the good first issuereverse proxynew feature labels 2026-04-20 07:20:57 -05:00
GiteaMirror commented 2026-04-20 07:20:59 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2774088097 --> @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!
GiteaMirror commented 2026-04-20 07:20:59 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2794710337 --> @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.
GiteaMirror commented 2026-04-20 07:21:00 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2810094319 --> @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.
GiteaMirror commented 2026-04-20 07:21:01 -05:00
Author
Owner
Copy Link

@mschirrmeister commented on GitHub (Apr 30, 2025):

Is https://github.com/fosrl/pangolin/pull/501 going to address this?

<!-- gh-comment-id:2843186443 --> @mschirrmeister commented on GitHub (Apr 30, 2025): Is https://github.com/fosrl/pangolin/pull/501 going to address this?
GiteaMirror commented 2026-04-20 07:21:02 -05:00
Author
Owner
Copy Link

@miloschwartz commented on GitHub (May 1, 2025):

@mschirrmeister I believe so

<!-- gh-comment-id:2843843950 --> @miloschwartz commented on GitHub (May 1, 2025): @mschirrmeister I believe so
GiteaMirror commented 2026-04-20 07:21:03 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2847821608 --> @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.
GiteaMirror commented 2026-04-20 07:21:03 -05:00
Author
Owner
Copy Link

@mschirrmeister commented on GitHub (May 2, 2025):

Just tested 1.3.0 and all looks good. Thank you very much.

<!-- gh-comment-id:2847848567 --> @mschirrmeister commented on GitHub (May 2, 2025): Just tested `1.3.0` and all looks good. Thank you very much.
GiteaMirror commented 2026-04-20 07:21:04 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2864118390 --> @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.
GiteaMirror commented 2026-04-20 07:21:05 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2864124022 --> @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.
GiteaMirror commented 2026-04-20 07:21:06 -05:00
Author
Owner
Copy Link

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

  1. Set TLS Server Name
  2. Setting gets reflected properly in DB
  3. Set Host Header
  4. Host Header gets set, but TLS Server Name setting gets removed.
  5. Set TLS Server Name (again).
  6. Host Header Setting gets removed.
    ...

Settings should not be coupled this way.

@miloschwartz @4nx

<!-- gh-comment-id:2864271466 --> @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: 1) Set TLS Server Name 2) Setting gets reflected properly in DB 3) Set Host Header 4) Host Header gets set, but TLS Server Name setting gets removed. 5) Set TLS Server Name (again). 6) Host Header Setting gets removed. ... Settings should not be coupled this way. @miloschwartz @4nx
GiteaMirror commented 2026-04-20 07:21:07 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2864926655 --> @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.
GiteaMirror commented 2026-04-20 07:21:08 -05:00
Author
Owner
Copy Link

@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 Header is the field for all http level stuff and to find the correct virtual host.

The TLS stuff is only important during the TLS handshake.

<!-- gh-comment-id:2865337759 --> @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 Header` is the field for all http level stuff and to find the correct _virtual host_. The TLS stuff is **only** important during the TLS handshake.
GiteaMirror commented 2026-04-20 07:21:08 -05:00
Author
Owner
Copy Link

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

<!-- gh-comment-id:2866573488 --> @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!
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 good first issue new feature reverse proxy
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#3404
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?