[FEAT / BUG] <Modifiable 'ListenPort' used by host/wireguard incoming connections through docker configuration>

[ohPaco]

[FEAT / BUG]

from docker-wireguard.

[github-actions]

Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.

[aptalca]

but does not mention a single thing about why the 'ListenPort' set in generated server wireguard config doesn't / shouldn't match the docker specified host port used for wireguard.

Why should it? It's called external port, which is the port used by the remote client. It is the port that is publicly available. It can be a completely different port forwarded by your router/firewall, or a different port mapped on your host. Nothing to do with the container listen port. You can set all three of those ports I just mentioned differently on your system (ie. public port 9999 forwarded to docker host port 8888 on router, docker service mapping host port 8888 to container port 51820). The env var in question only cares about the external public port, which you would set to 9999 and not 8888 or 51820.

Next, its stated in #175 that "There is also no reason for you to change [the listen port]". Completely untrue, for example, in the instance that a previous wireguard configuration on system or other program is using port 51820.
Having multiple simultaneous wireguard configurations using different ports on a single client or even host has it's use cases. One shouldn't have to modify a field in an autogenerated and undocumented fine in order to allow this to work.

Map the ports however you like:
https://docs.docker.com/network/#published-ports

[ohPaco]

but does not mention a single thing about why the ListenPort set in generated server wireguard config doesn't / shouldn't match the docker specified host port used for wireguard.

Why should it? It's called external port

I think there’s a misinterpretation here.
I’m saying, the ListenPort in generated host wireguard config should match the host port set here:

Map the ports however you like:
https://docs.docker.com/network/#published-ports

Example: Assume one sets mapping as -p 51824:80.
In this case, ListenPort of host (under [Interface] in file wg_confs/wg0.conf) should set to/generated with value 51824.

external port, which is the port used by the remote client. It is the port that is publicly available. It can be a completely different port forwarded by your router/firewall

I agree totally, the ListenPort in generated peer wireguard config(s) set throughSERVERPORT value doesn’t have to correlate with either docker host container port. You explain that in #182.

[aptalca]

Example: Assume one sets mapping as -p 51824:80.
In this case, ListenPort of host (under [Interface] in file wg_confs/wg0.conf) should set to/generated with value 51824.

No. -p 51824:80 would mean the container port (aka wireguard's listen port) has to be 80 for the connection to succeed. In port mapping, left side is host port, right side is container port.

Container port is always 51820. SERVERPORT should be set to the public port exposed, along with SERVERURL set to the public url or IP. Everything else is irrelevant to the container.

[ohPaco]

-p 51824:80 would mean the container port (aka wireguard's listen port) has to be 80 for the connection to succeed.

Right, so it seems it’d be logical to have to automatically have the program set the ListenPort of host (under [Interface] in file wg_confs/wg0.conf) as the container port value set in docker port mapping.
Is there any reason why this shouldn’t be implemented if these two ports MUST match ?

Container port is always 51820.

Do you mean the container port will remain 51820 even if one modifies the container port via docker ? Eg. -p 51824:80. If so, why is this the case? Sounds problematic.

[aptalca]

No offense, but you need to read up on the general concept of docker port mapping to get up to speed.

Right, so it seems it’d be logical to have to automatically have the program set the ListenPort of host (under [Interface] in file wg_confs/wg0.conf) as the container port value set in docker port mapping.
Is there any reason why this shouldn’t be implemented if these two ports MUST match ?

No. They don't need to match. I don't know how else to explain it to you other than what I wrote above.

Do you mean the container port will remain 51820 even if one modifies the container port via docker ?

That's how docker port mapping works. That's the point of it. Container port remains the same, host port can be anything you want.

Eg. -p 51824:80. If so, why is this the case? Sounds problematic.

You wouldn't do that. You would do -p XXXX:51820 with XXXX being whatever port you want to map on the host.

You really need to read up more. I don't have the bandwidth to continue this discussion any longer.

[ohPaco]

I'm familiar with how port mapping using docker works.

No. They don't need to match. I don't know how else to explain it to you other than what I wrote above.

HostListenPort field’s value (under [Interface] in file wg_confs/wg0.conf) needs to match container port according to your comments in #161 and according to my own experience with this docker container.

So it shouldn’t be hard coded to 51820 if the container port can be changed through docker cli/compose.

It’s an issue that has come up plenty of times and still hasn’t gotten a clear fix or documentation explanation. If the program doesn’t want to work in an automated fashion if a user changes the mapped container port then either; specify “DO NOT CHANGE” in your documentation, or make the server ListenPort field match the set container port, and not hard coded.

Is that fair, or is your answer still “no, the program will not work when used this way. you should know this port mapping configuration is a requirement” while this requirement it’s not stated once in documentation, or clearly in your responses .. ?

In #51 you do say :

you can map internal port 51820 to whatever port you like

So, my suggestion is that the field in question should be generated to match this port.

[JoshStark]

So it shouldn’t be hard coded to 51820 if the container port can be changed through docker cli/compose.

if I have understood this point correctly, you would like to change the container port. generally speaking this field is set to a value that the internal application inside the container is listening on. It should never need to be changed. That is what the host port is for.

For those who run multiple instances of the WireGuard container, it is sufficient to change only the host port mapping to avoid port conflicts (assuming each container is running in a bridge network mode).

Do you mean the container port will remain 51820 even if one modifies the container port via docker ? Eg. -p 51824:80. If so, why is this the case? Sounds problematic.

The idea of not changing the container-side port value in -p usage is at this point effectively enshrined in how Docker containers are utilised. What you are describing above would apply to any Docker container.

Port 51820 is what WireGuard listens on. If you want or need a different port to be used due to either port conflicts on the host or other reasons (which I’m struggling to find, as at container level it really doesn’t matter at this point) then you just need to modify the host-side value in the port mapping, e.g -p 58124:58120.