Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature request: send ports forwarded to control server #2369

Open
jagaimoworks opened this issue Jul 26, 2024 · 6 comments
Open

Feature request: send ports forwarded to control server #2369

jagaimoworks opened this issue Jul 26, 2024 · 6 comments

Comments

@jagaimoworks
Copy link

What's the feature 🧐

I suggest adding runtime control of the forwarded ports to the control server.

This would greatly improve the users ability to create their own port forwarding solutions for VPN providers that have no native port forwarding implementation within Gluetun (i.e. Perfect Privacy #2368).

Extra information and references

No response

Copy link
Contributor

@qdm12 is more or less the only maintainer of this project and works on it in his free time.
Please:

@qdm12
Copy link
Owner

qdm12 commented Jul 30, 2024

I suggest adding runtime control of the forwarded ports to the control server.

I'm not sure I follow what you request here? 🤔
Do you mean for example running a script when the tunnel is up? If so there is #1785 which I should do sometime soon hopefully.

@jagaimoworks
Copy link
Author

jagaimoworks commented Jul 31, 2024

The basic idea was to implement a HTTP PUT route for the port forwarded API endpoint. With this people could implement external solutions for their port forwarding scenario where Gluetun doesn´t yet support the provider, like running their own scripts in another container and controlling Gluetun from there.

However, seeing how fast support for Perfect Privacy got implemented there probably is no need for this feature,
assuming other VPN providers can get similar treatment when requested.

Lastly, #1785 would definitely allow for custom solutions like this, but being able to use the Control Server API to control Gluetun externally seems generally more elegant to me, especially as with scripting within the Gluetun container people would need to install all the additional tools they would want to use within their scripts.

@qdm12
Copy link
Owner

qdm12 commented Aug 1, 2024

The basic idea was to implement a HTTP PUT route for the port forwarded API endpoint

Can you give an example? Let's say for perfect privacy, how would you apply this? 🤔
It might be simpler to just do a pull request and add the functionality in the Go code directly maybe? If so, I would need to add documentation on how to do it, which would be a good addition anyway (even for my future self 😄)

@jagaimoworks
Copy link
Author

jagaimoworks commented Aug 1, 2024

In the case of Perfect Privacy one could create an additional container connected to Gluetun and monitor the internal tunnel address changes. When a change happens you run Perfect Privacy's script to calculate the new forwarded ports and then PUT them at /v1/openvpn/portforwarded with {"port":[12345,12346,12347]} as the request body. Gluetun should then update its firewall and settings accordingly.

Alas, my proficiency with Go as well as my understanding of the port forwarding code still needs quite a bit of work before I would attempt a pull request. 😅

@qdm12
Copy link
Owner

qdm12 commented Aug 1, 2024

That's interesting. The current workarounds are implement the code in Go in Gluetun AND use FIREWALL_VPN_INPUT_PORTS to specify forwarded ports at start. But indeed, with this, you could have the logic of perfect privacy port forwarding request in another container and send it to Gluetun. Good idea! Not a priority though, but I'll eventually do it 😉

@qdm12 qdm12 changed the title Feature request: runtime control over forwarded ports Feature request: send ports forwarded to control server Aug 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants