central pangolin server or custom traefik proxy - hardware device 001
kubehost01 - hardware device 002
kubecontainer001 - 10.10.10.100
newt tunneler or tailscale (for example)
server1 on 0.0.0.0:1111
kubecontainer002 - 10.10.10.200
server2 on 0.0.0.0:2222
kubecontainer003 - 10.10.10.300
server3 on 0.0.0.0:3333
Hello! Love the service. I wanted to query a developer on best practice for deployment/implementation.
With tailscale running in an example kubernetes cluster in kubecontainer001, I can run tailscale up --authkey KEY --login-server https://headscale.domain --advertise-routes=10.10.1.200/32,10.10.1.100/32.
This allows me to route/proxy to any of the 3 kube containers with only one running tunnel. For example, I could then route server3.traefik.domain -> 10.10.10.300:3333. Does this subnet routing feature exist with Pangolin? And if it does, how would it be possible to proxy servers 1-3 from one tunnel?
I believe Pangolin can work with newt and wireguard? So the feature should be possible if not already implemented via wireguard. Pangolin would need to be updated along with newt to take multiple endpoints and ips as host I think. I've only seen newt startup with one endpoint, so I'm beginner, correct me If I'm wrong. I would be interested in implementing the feature if it's not a current priority. The CLI tools and proxy would need to be made aware of these changes. Traefik is being modified via API?
Feel free to link to docs or code. I just haven't found any specific discussion on this outside of a few issues. I appreciate the time!
Originally created by @NotChristianGarcia on GitHub (May 6, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/686
**Network:**
- central pangolin server or custom traefik proxy - hardware device 001
- kubehost01 - hardware device 002
- `kubecontainer001` - `10.10.10.100`
- newt tunneler or tailscale (for example)
- server1 on `0.0.0.0:1111`
- `kubecontainer002` - `10.10.10.200`
- server2 on `0.0.0.0:2222`
- `kubecontainer003` - `10.10.10.300`
- server3 on `0.0.0.0:3333`
Hello! Love the service. I wanted to query a developer on best practice for deployment/implementation.
With tailscale running in an example kubernetes cluster in `kubecontainer001`, I can run `tailscale up --authkey KEY --login-server https://headscale.domain --advertise-routes=10.10.1.200/32,10.10.1.100/32`.
This allows me to route/proxy to any of the 3 kube containers with only one running tunnel. For example, I could then route `server3.traefik.domain -> 10.10.10.300:3333`. Does this subnet routing feature exist with Pangolin? And if it does, how would it be possible to proxy servers 1-3 from one tunnel?
I believe Pangolin can work with newt and wireguard? So the feature should be possible if not already implemented via wireguard. Pangolin would need to be updated along with newt to take multiple endpoints and ips as host I think. I've only seen newt startup with one endpoint, so I'm beginner, correct me If I'm wrong. I would be interested in implementing the feature if it's not a current priority. The CLI tools and proxy would need to be made aware of these changes. Traefik is being modified via API?
Feel free to link to docs or code. I just haven't found any specific discussion on this outside of a few issues. I appreciate the time!
@github-actions[bot] commented on GitHub (May 21, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
<!-- gh-comment-id:2896124328 -->
@github-actions[bot] commented on GitHub (May 21, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 4, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
<!-- gh-comment-id:2937857876 -->
@github-actions[bot] commented on GitHub (Jun 4, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @NotChristianGarcia on GitHub (May 6, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/686
Network:
kubecontainer001-10.10.10.1000.0.0.0:1111kubecontainer002-10.10.10.2000.0.0.0:2222kubecontainer003-10.10.10.3000.0.0.0:3333Hello! Love the service. I wanted to query a developer on best practice for deployment/implementation.
With tailscale running in an example kubernetes cluster in
kubecontainer001, I can runtailscale up --authkey KEY --login-server https://headscale.domain --advertise-routes=10.10.1.200/32,10.10.1.100/32.This allows me to route/proxy to any of the 3 kube containers with only one running tunnel. For example, I could then route
server3.traefik.domain -> 10.10.10.300:3333. Does this subnet routing feature exist with Pangolin? And if it does, how would it be possible to proxy servers 1-3 from one tunnel?I believe Pangolin can work with newt and wireguard? So the feature should be possible if not already implemented via wireguard. Pangolin would need to be updated along with newt to take multiple endpoints and ips as host I think. I've only seen newt startup with one endpoint, so I'm beginner, correct me If I'm wrong. I would be interested in implementing the feature if it's not a current priority. The CLI tools and proxy would need to be made aware of these changes. Traefik is being modified via API?
Feel free to link to docs or code. I just haven't found any specific discussion on this outside of a few issues. I appreciate the time!
@github-actions[bot] commented on GitHub (May 21, 2025):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@github-actions[bot] commented on GitHub (Jun 4, 2025):
This issue has been automatically closed due to inactivity. If you believe this is still relevant, please open a new issue with up-to-date information.