Wireguard leaks IP address in client mode if connection fails

[master-hax]

---

Expected Behavior

the command curl api.ipify.org from within the container should fail if the VPN connection is not up

Current Behavior

the command curl api.ipify.org from within the container succeeds & shows the docker host's external IP address if the VPN connection is not up

Steps to Reproduce

1. put a valid wg0.conf in ./config
2. start this docker-compose file to run wireguard in client mode:

version: "3.7"
  services:
    vpn-client:
        image: linuxserver/wireguard
        restart: unless-stopped
        cap_add:
          - NET_ADMIN
          - SYS_MODULE
        environment:
          - TZ=America/Los_Angeles
        volumes:
          - /lib/modules:/lib/modules
          - ./config:/config
        sysctls:
          - net.ipv4.conf.all.src_valid_mark=1
          - net.ipv6.conf.all.disable_ipv6=0

2. run docker exec -it vpn-client_1 curl api.ipify.org. you will see the IP address of your VPN server exit node as expected.
3. delete ./config/wg0.conf then run docker restart vpn-client_1. now the connection should fail. we can confirm from the logs:

**** Client mode selected. ****
**** No client conf found. Provide your own client conf as "/config/wg0.conf" and restart the container. ****

4. run docker exec -it vpn-client_1 curl api.ipify.org again. we expect the request to fail this time, but instead you will see the external IP address of the docker host

Environment

OS: dietpi
CPU architecture: x86_64/arm32/arm64
How docker service was installed: i don't remember

Command used to create docker container (run/create/compose/screenshot)

Docker logs

[github-actions]

Thanks for opening your first issue here! Be sure to follow the bug or feature issue templates!

[aptalca]

Wireguard leaks IP address in client mode if connection fails

That's an inaccurate statement. The test you're performing is not of a failed connection, but of a scenario where wireguard is not even started. If there is no wg0.conf, all the container does is print an error message in the log and then run a single process of sleep infinite. No wireguard interface is created, no iptables rules or routes set. There is no connection to fail. At that point it's just a plain Ubuntu container with a sleep process running inside of it, using the docker network it's set up with.

An accurate test would be to first set it up with a valid wg0.conf, make sure it works as expected, then edit it to make a breaking change (like the server address, or the public key, etc.) and then see if there is a connection and/or if anything is leaking. You'll see that the outbound connections will still be attempted, the encrypted packets will still be sent out, but it won't hear anything back because the packets will never reach their destination properly. So the container will experience a loss of connection.

[master-hax]

the fast response is very much appreciated 🙂

i just tested what you mentioned with a malformed wg0.conf & curl api.ipify.org indeed failed.

two thoughts i still have:

1. can we consider forcing container death if wg0.conf is missing? if wireguard doesn't even start in that scenario, it seems both incorrect & unexpected to leave the container up & running in host network mode
2. even with a malformed wg0.conf, there is a few second window immediately after the container starts when the curl command does work and leaks the IP. i don't know if this is unavoidable due to the time it takes wireguard to start but i just thought i would bring it up.

[aptalca]

If there isn't a wg0.conf, it means wireguard is not configured. If you were to simply install the wireguard package on bare metal on a regular linux machine, but not configure it, you can't expect the internet to not work until wireguard is configured. That's not how it works.

Even if there is a wg0.conf and a wireguard tunnel set up, it doesn't necessarily mean IP won't leak (or if anything will go through the tunnel at all). It's all configured via the parameters in wg0.conf (ie. AllowedIPs). Without that, the container would have absolutely no knowledge of what your intentions are.

Also, the container still needs an internet connection, otherwise it can't connect to the wireguard server when creating the tunnel.

If you're worried about the split second after container start before wireguard tunnel creation, you can add a custom delay for the downstream container's init. Mullvad for instance has an api endpoint you can hit to make sure the connection goes through them.
https://www.linuxserver.io/blog/2019-09-14-customizing-our-containers

[laurids-reichardt]

I share the concern expressed above. I believe that if anyone uses this image to route traffic of another container exclusively through WireGuard, they won't want their host IP address leaking under any circumstance.

My WireGuard and networking knowledge is very limited, but the section The New Namespace Solution of the official WireGuard documentation caught my eye: https://www.wireguard.com/netns/

Could the eth0 interface live inside a separate network namespace, as described inside the article, to prevent any connection going through it, even in case the wg0 interface isn't running yet or goes down?

[aptalca]

I don't think you understand what I wrote above. That article is telling you to configure it a certain way. What you're asking me is a scenario where you refuse to configure it at all and expect it to drop the internet connection.

Just configure it as you should (by putting in a wg0.conf, which you only have to do once, when you first set it up), then it will work as expected.

EDIT: to further clarify. as long as it's configured once, even if the configuration is not correct (but valid, meaning wireguard does not error out), your details won't leak as the packets will be sent to ether effectively appearing as no internet connection. But you have to configure it by providing a valid wg0.conf so the tunnel gets created (again, the tunnel may not go anywhere, but it needs to be there)

[drizuid]

Just to add a little here, if you dont understand VPNs and networking, as least at a basic fundamental level, a vpn isn't necessarily protecting you. That's not on us, users are responsible for their configurations AND understanding their configurations.

[laurids-reichardt]

@aptalca I appreciate your feedback. I understand your point that once a valid configuration is provided and the tunnel created, no unencrypted packages should leak.

My concern lays with two scenarios:

1. As you previously stated, there's a short gap between the time the container starts and the WireGuard tunnel is created.
2. If, for whatever unlikely reason, the wg0 interface goes down, all traffic seems to go through the unencrypted eth0 interface. I tried to confirm this via the following commands:

docker exec -it wireguard bash
ip link set wg0 down
curl api.ipify.org

As I'm not particular experienced with WireGuard, my question is whether the namespace configuration mentioned in the linked WireGuard article would prevent both scenarios. Is the following file the right place to try implementing such a configuration? https://github.com/linuxserver/docker-wireguard/blob/master/root/etc/services.d/wireguard/run

[aptalca]

As you previously stated, there's a short gap between the time the container starts and the WireGuard tunnel is created.

You have the same issues on bare metal so nothing is different here. We also don't make any such guarantees about leakage. We don't even officially provide support for using this in client configuration. It's in the readme. The reason is that we don't want to give you the false sense of security. If you want to use this in client mode to be totally private, you need to know what you're doing. You can easily customize your downstream container (assuming it's lsio) to add a delay on start and check for the tunnel but that's on you.

If, for whatever unlikely reason, the wg0 interface goes down, all traffic seems to go through the unencrypted eth0 interface. I tried to confirm this via the following commands:

You'd need to give us a real world scenario where the tunnel goes down on its own, not one where you manually bring it down.

[laurids-reichardt]

Thanks for the feedback. Mullvad seems to mitigate the second scenario by adding the following lines to the supplied WireGuard conf:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

[davidfrickert]

Thanks for the feedback. Mullvad seems to mitigate the second scenario by adding the following lines to the supplied WireGuard conf:

PostUp = iptables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -I OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT && ip6tables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

@laurids-reichardt, do these configs work for you?
I get iptables: No chain/target/match by that name. sadly, running in armv8 platform (raspberry pi 4)

[laurids-reichardt]

@davidfrickert Yes. Check if the appropriate iptable chains exist with the following command: iptables -L -v

More information: https://linux.die.net/man/8/iptables

[davidfrickert]

Thanks! I ran that command inside the linuxserver/wireguard container and got this

root@e24380837a64:/# iptables -L -v
Chain INPUT (policy ACCEPT 3274K packets, 2240M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 3343K packets, 1704M bytes)
 pkts bytes target     prot opt in     out     source               destination
23768   34M ACCEPT     all  --  any    any     anywhere             192.168.0.0/16

I have very little understanding of iptables, but I seem to have all needed chains right? It's probably another part of the command that isn't working I guess.

[laurids-reichardt]

@davidfrickert Yeah sorry, I won't be able to help you debug the issue.

Here's something you could try. Try to manually execute the iptable commands inside the running container and see what comes up: docker exec -it wireguard bash