github-starred/pangolin
2
0
Fork 0
mirror of https://github.com/fosrl/pangolin.git synced 2026-05-08 13:49:15 -05:00
Code Issues 564 Packages Projects Releases 72 Wiki Activity

[GH-ISSUE #345] Feature Request - Internal Service Exposure & Hub Function #8168

New Issue
Closed
opened 2026-04-30 03:36:37 -05:00 by GiteaMirror · 4 comments
GiteaMirror commented 2026-04-30 03:36:37 -05:00
Owner
Copy Link

Originally created by @miloschwartz on GitHub (Mar 16, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/345

Originally assigned to: @oschwartz10612, @miloschwartz on GitHub.

Discussed in https://github.com/orgs/fosrl/discussions/23

Originally posted by Zetsuubou January 10, 2025
As previously conceived on the discord server this feature request would change the direction of the project significantly.

Pangolin currently allows services to be exposed to the public through the usage of Newt or Wireguard.
However, it would be useful to be able to leverage the SSL certificates, authentication layer and general user management to also expose services on an internal Pangolin network and make those services available to other users, which can be invited to Pangolin.

The general idea here would be to have similar functionality to Tailscale, where the Pangolin server could act as a centralized hub to facilitate connections between different Newt/Wireguard nodes, whether they are services or users wanting to gain access to the aforementioned.

Summary of feature request
Existing:
Pangolin remains being able to expose services publicly like it does currently.

New or carried over features:
Pangolin can expose services on an internal network.

  • Valid SSL certificates; either through regular challenges or DNS challenge/API.
  • DNS-01 challenge added as an option to the web interface, instead of editing through configuration files.
  • Same Pangolin authentication like on public facing services, but for internal ones as well.

Pangolin on a VPS could act as a relay for traffic (if direct connections aren't possible or subpar), which might also have to be packaged into its own separate service, so that organizations or prosumers can organize a larger selection of relays in different locations.

Users that are added to the internal network should get segmented into their own subnet or otherwise restricted, so that they can only access resources by going through Pangolin first, unless specifically allowed to be on the same network by an administrator.

Perhaps introduce options to enable/disable exposing a service to the public or internally or both at the same time.

Cheers 👍

Originally created by @miloschwartz on GitHub (Mar 16, 2025). Original GitHub issue: https://github.com/fosrl/pangolin/issues/345 Originally assigned to: @oschwartz10612, @miloschwartz on GitHub. ### Discussed in https://github.com/orgs/fosrl/discussions/23 <div type='discussions-op-text'> <sup>Originally posted by **Zetsuubou** January 10, 2025</sup> As previously conceived on the discord server this feature request would change the direction of the project significantly. Pangolin currently allows services to be exposed to the public through the usage of Newt or Wireguard. However, it would be useful to be able to leverage the SSL certificates, authentication layer and general user management to also expose services on an internal Pangolin network and make those services available to other users, which can be invited to Pangolin. The general idea here would be to have similar functionality to Tailscale, where the Pangolin server could act as a centralized hub to facilitate connections between different Newt/Wireguard nodes, whether they are services or users wanting to gain access to the aforementioned. **Summary of feature request** Existing: Pangolin remains being able to expose services publicly like it does currently. **New or carried over features:** Pangolin can expose services on an internal network. - Valid SSL certificates; either through regular challenges or DNS challenge/API. - DNS-01 challenge added as an option to the web interface, instead of editing through configuration files. - Same Pangolin authentication like on public facing services, but for internal ones as well. Pangolin on a VPS could act as a relay for traffic (if direct connections aren't possible or subpar), which might also have to be packaged into its own separate service, so that organizations or prosumers can organize a larger selection of relays in different locations. Users that are added to the internal network should get segmented into their own subnet or otherwise restricted, so that they can only access resources by going through Pangolin first, unless specifically allowed to be on the same network by an administrator. Perhaps introduce options to enable/disable exposing a service to the public or internally or both at the same time. Cheers 👍 </div>
GiteaMirror added the new feature label 2026-04-30 03:36:37 -05:00
GiteaMirror commented 2026-04-30 03:36:39 -05:00
Author
Owner
Copy Link

@LeonvanHeerden commented on GitHub (Mar 16, 2025):

This would be a great feature and something that I am looking for.

What about adding a new SITE type, that is Locally Routed or a Restricted to a specific subset of existing sites. This can potentially also be managed through roles.

That way the new site can only communicate to or through the selected sites, and you can restrict the access to only a specific set of sites or Roles.

<!-- gh-comment-id:2727612098 --> @LeonvanHeerden commented on GitHub (Mar 16, 2025): This would be a great feature and something that I am looking for. What about adding a new SITE type, that is Locally Routed or a Restricted to a specific subset of existing sites. This can potentially also be managed through roles. That way the new site can only communicate to or through the selected sites, and you can restrict the access to only a specific set of sites or Roles.
GiteaMirror commented 2026-04-30 03:36:40 -05:00
Author
Owner
Copy Link

@A4alli commented on GitHub (Mar 24, 2025):

tailscale integration is MUST

<!-- gh-comment-id:2749164861 --> @A4alli commented on GitHub (Mar 24, 2025): tailscale integration is MUST
GiteaMirror commented 2026-04-30 03:36:40 -05:00
Author
Owner
Copy Link

@BenRoe commented on GitHub (May 16, 2025):

In addition to this feature, an option to disable authentication if access via local network would be useful.

<!-- gh-comment-id:2886934632 --> @BenRoe commented on GitHub (May 16, 2025): In addition to this feature, an option to disable authentication if access via local network would be useful.
GiteaMirror commented 2026-04-30 03:36:40 -05:00
Author
Owner
Copy Link

@oschwartz10612 commented on GitHub (Jul 31, 2025):

I think closed by 1.8.0!

<!-- gh-comment-id:3140757361 --> @oschwartz10612 commented on GitHub (Jul 31, 2025): I think closed by 1.8.0!
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 new feature
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#8168
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?