gluetun
gluetun copied to clipboard
Send ports forwarded to control server
First timer here. This is a somewhat working implementation of #2369. Hit me with the improvements I can take it :sweat_smile:
I say somewhat working because the removal of ports from the firewall suffers from #2334 and therefore does not reliably work right now.
The way it works right now is by sending a http PUT request with a body like {ports: [1234, 3456]} to /v1/openvpn/portforwarded.
(Sort of) blocked by #1785
Blocked by #2238 as well.
Hello! Any news on this PR ?
@jagaimoworks By the way:
- Great work! ❤️
- Sorry for the delay re-reviewing this 🕐
- Just a few minor comments ✅
And @andy3469 I'm curious, what do you plan to use this PR for 😃?
And @andy3469 I'm curious, what do you plan to use this PR for 😃?
I plan to use it with https://github.com/dhruvinsh/ws-ephemeral as a way to update the port every week. I will do a PR on the other project once this one is up and running 😄
@jagaimoworks All done 😉 I rebased your branch on the master branch, pushed a few commits to simplify and re-use the same setup and teardown code for both the normal service operation and this patch request. One last thing I would like to ask you (or @andy3469 ?), is to PR to https://github.com/qdm12/gluetun-wiki a section explaining how this works, why etc. in https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md and perhaps link that section in https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md as well 😉
@jagaimoworks All done 😉 I rebased your branch on the master branch, pushed a few commits to simplify and re-use the same setup and teardown code for both the normal service operation and this patch request. One last thing I would like to ask you (or @andy3469 ?), is to PR to https://github.com/qdm12/gluetun-wiki a section explaining how this works, why etc. in https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/control-server.md and perhaps link that section in https://github.com/qdm12/gluetun-wiki/blob/main/setup/advanced/vpn-port-forwarding.md as well 😉
I will do it this weekend if I have the time to read and understand the changes.
Sorry for taking so long to respond.
@qdm12 I think commit 19a007f5e51df628368181b0a7f569291c09f119 broke something.
Trying to PUT ports like { "ports": [1234] } hangs indefinitely and blocks the control server for any further requests.
Also, I assume that we still have to add our PUT route to the list of valid routes in the authentication code.
Lastly, if @andy3469 hasn't done so already, I will gladly provide documentation on this features usage.
Update: Here is the PR for the wiki: https://github.com/qdm12/gluetun-wiki/pull/126
Any news on the PR ?
This is also the final piece for me to use an custom VPN provider where the workflow is;
- Request port forward through internal API (only accessible from within VPN tunnel, thuss needs to be done in Gluetun container or one using service_mode)
- Take given (not choosen) port number and update actual client software so that it listens on correct port
- ... and update the Gluetun firewall to open the assigned port
news on this? Would love to be able to set the port forwarding based on the ephemeral port from windscribe automatically
@qdm12 @jagaimoworks thank you both for the efforts in getting us where we are on this feature. Do you think this is close to being reviewed and being merged? I understand there are many different issues and features being worked on, but it would be a shame for this to be held up for so long given that we're so close (unless there is some discussion of going in a completely different direction implementation wise). Thank you both once again.
First of all my apologies everyone with the massive delay. Life got in the way (family, work, health etc.) and I've been halted on Gluetun work for a good part of 2025. But I should be back now 💪
I think commit 19a007f broke something.
Indeed, my apologies again, fixed in https://github.com/qdm12/gluetun/pull/2392/commits/539fdebc315ff19f6893db9c2178aba85a20e680
Also, I assume that we still have to add our PUT route to the list of valid routes in the authentication code.
Yes. Since this is a new route, no reason to have is not secured.
Working on one last thing: moving /v1/openvpn/portfowarded -> /v1/portfoward on the master branch. Then change it here as well. The port fowarding has nothing to do with openvpn really, so it's worth separating and not cluttering more this wrong name. Should be done today.
Will merge this as soon as v3.41.0 is out