[BUG] Client IPs are all the container's host

[bobbyl140]

Is there an existing issue for this?

• [X] I have searched the existing issues

Current Behavior

When running wg show in the container, all the IPs are the host system's IP on the Docker subnet.

Expected Behavior

If possible, these should be the real IPs.

Steps To Reproduce

1. Get a working container with Podman on Rocky Linux 9.3
2. Connect a client
3. Run podman exec -it wireguard wg show
4. Notice the client's IP being the Docker host's

Environment

- OS: Rocky Linux 9.3
- How docker service was installed: Podman, from OS install media

CPU architecture

x86-64

Docker creation

version: "3.8"
services:
  wireguard:
    image: lscr.io/linuxserver/wireguard:latest
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - NET_RAW
      - SYS_MODULE
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    volumes:
      - /root/wireguard/config:/config
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=America/New_York
      - SERVERURL=auto
      - SERVERPORT=51820 #optional
      - PEERS=1 #optional
      - PEERDNS=1.1.1.1 #optional
      - INTERNAL_SUBNET=172.24.5.0 #optional
      - ALLOWEDIPS=0.0.0.0/0 #optional
      - PERSISTENTKEEPALIVE_PEERS=all #optional
      - LOG_CONFS=true #optional
    restart: always

Container logs

N/A

[github-actions[bot]]

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

[github-actions[bot]]

A human has marked this issue as invalid, this likely happened because the issue template was not used in the creation of the issue.

[drizuid]

you've not provided enough info.

1. we do not support podman, ignoring this though
2. you state the IPs are on the host and dont share what those IPs are for comparison.
3. you provide no network information to help tshoot your network problem (which only you have ever reported)

[bobbyl140]

1. I'm sorry, I didn't think it would matter. Podman came with my OS so I just went with it.
2. The IPs shouldn't really matter since they don't create or take away the problem, but the output of wg show is as follows: endpoint: 192.168.25.145:55156 The endpoint's address is obviously not within the Docker subnet because it's a physical device on cellular.
3. What information would you like? I'm not sure how to help here.

[drizuid]

we only test and support docker, podman can do things differently. We definitively do not support rootless podman, though it can also work

The IPs CAN matter when you describe an issue involving the IPs being on the host but show nothing about the IPs. for example a common issue we see are people making their wireguard subnet be the same as their lan subnet. It would show what you described and would be an unsupported config.

so for info, your statement is that client IPs (assuming wireguard clients?) are all on the container host. your INTERNAL_SUBNET=172.24.5.0 #optional means your clients should have an IP in the 172.24.5.0/24 range

when you show that endpoint, my assumption is that your home LAN is 192.168.25.0/24 perhaps? (this is why IPs matter, im having to make assumptions), so if this is what you mean by client ips are the container's host, then yes, this is abnormal and makes it look as if you were connecting to the VPN from within your LAN (like on wifi) but if your docker host itself IS 192.168.25.145, then you have something weird setup. Nothing stands out in your compose and it's similar to mine. My suggestion is to test using docker, but in the meantime I'll see if anyone wants to take a look at this (but dont get your hopes up, as it's unsupported)

[bobbyl140]

Hi, I'm sorry, I see what you're saying now. I apologize for being blunt. My home LAN is 10.0.0.0/24, the Docker (Podman) subnetting I have includes the 192.168.25.0/24 range. So when I connect from a client, no matter on my home LAN, on cellular, or anywhere else, it always shows the client's IP as my host machine's IP on that Docker subnet. The internal subnet I have set to 172.24.5.0/24 to align with my other VPN services elsewhere.

[drizuid]

to ensure i understand, do you mean that when your vpn'd client accesses something (say.. a webpage) which shows what IP connected to it, you are seeing your docker host ip? if yes, that is normal. docker (and podman) nat things from inside the container to the outside so the source is your docker host. similarly when you have a single public ip and your many hosts internally access an external site, they all see that one WAN ip. To NOT have that happen, and this is very out of scope of support, you would need to ROUTE that traffic rather than NAT it.

[bobbyl140]

No, the IP shown on https://whatismyipaddress.com is in fact the WAN IP of my Docker host. That I expect. The issue is, for administrative purposes, I'd like to be able to see from the Docker host where clients are connecting from (say, the IP of a coffee shop). Which I realize may or may not be possible due to how Docker works, but if this is something that can be changed, that would be a useful feature. For example, running wg show on my server with native WireGuard shows the public IP of the client outside of the VPN tunnel.

[bobbyl140]

Now that I think about it, would this be possible with a bridged network setup for this Docker container?

[drizuid]

No, the IP shown on https://whatismyipaddress.com is in fact the WAN IP of my Docker host. That I expect. The issue is, for administrative purposes, I'd like to be able to see from the Docker host where clients are connecting from (say, the IP of a coffee shop). Which I realize may or may not be possible due to how Docker works, but if this is something that can be changed, that would be a useful feature. For example, running wg show on my server with native WireGuard shows the public IP of the client outside of the VPN tunnel.

ahh you should be seeing that yes, in my endpoints, i see the public ip of the specific peer.

Now that I think about it, would this be possible with a bridged network setup for this Docker container?

in your compose, you are using a bridged network setup (which is what we support and recommend)

[bobbyl140]

I mean like adding network_mode: bridge, since that exposes the actual port on the host.

[drizuid]

I mean like adding network_mode: bridge, since that exposes the actual port on the host.

not typing any network mode means you are using bridge

[drizuid]

i think it might be best for you to come on our discord, truthfully, you have something going on and it's not a container issue, so probably best to sort it out in our live chat rather than ghi

[bobbyl140]

not typing any network mode means you are using bridge

I meant to say host networking. I'm sorry, it's been a while since I did that kind of thing in Docker and I don't have my terms straight by any means. As in, the ports aren't isolated over the virtual interface and are set up directly on the host.

i think it might be best for you to come on our discord, truthfully, you have something going on and it's not a container issue, so probably best to sort it out in our live chat rather than ghi

Fair enough. I'll join that soon.

[drizuid]

I meant to say host networking. I'm sorry, it's been a while since I did that kind of thing in Docker and I don't have my terms straight by any means. As in, the ports aren't isolated over the virtual interface and are set up directly on the host.

We don't support host, but you're already in an unsupported setup with podman, so IMO test all the things :D

Fair enough. I'll join that soon.

With that, I'll go ahead and close this and hopefully we can get you working on discord.