Comments (8)
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
from docker-wireguard.
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
from docker-wireguard.
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.
from docker-wireguard.
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.
from docker-wireguard.
-p 51824:80
would mean the container port (aka wireguard's listen port) has to be80
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.
from docker-wireguard.
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.
from docker-wireguard.
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.
from docker-wireguard.
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
.
from docker-wireguard.
Related Issues (20)
- [BUG] The requested image's platform (linux/arm64) does not match the detected host platform (linux/arm/v8) HOT 2
- [BUG] SERVERPORT is being ignored HOT 2
- [BUG] Ping peers HOT 1
- [BUG] SERVER_ALLOWEDIPS_PEER_* include quotes inside AllowedIPs peer variable HOT 6
- [BUG] Improvement of the documentation of the ALLOWEDIPS parameter. HOT 2
- [FEAT] mDNS (Avahi) support through Wireguard HOT 2
- [FEAT] Always-OnKill Switch in Client-mode HOT 3
- [BUG] Custom Server Port not taken into account in server.conf template HOT 3
- [BUG] starting with ~v1.0.20210914-ls116 cannot connect to wireguard HOT 3
- [BUG] Error generating QRCode - qrencode: command not found HOT 2
- [BUG] -ls23 and onwards has issue with adding iptables rules HOT 6
- [BUG] iptables v1.8.10 (legacy): can't initialize iptables table `filter' HOT 4
- [BUG] Conneted to the Wiregurad server, but no network connection on client side. HOT 3
- [BUG] Client IPs are all the container's host HOT 15
- [BUG] missing /32 in interface address HOT 14
- [FEAT] Enable SERVER_ALLOWEDIPS_PEER_ declaration by comma HOT 9
- Old tags are wrong HOT 4
- [BUG] ListenPort = 51820 in default peer.conf disallows >1 peer through NAT loopback HOT 11
- [FEAT] [Peer] definition within generated wg0.conf should be templated HOT 10
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docker-wireguard.