Container has no internet access about docker-wireguard HOT 24 CLOSED

Just adding a note for those who try to add
0.0.0.0/0 as an allowed IP.

This seems to result in this same exception but I am finding success using

0.0.0.0/1

Try that.. see if it solve the issue for you all

from docker-wireguard.

Hey, I am having the same issue with this container and using it as a wg client. Shows connected, but cannot resolve hostnames. It seems that /etc/resolv.conf is not getting updating when wg-quick up runs.

Current resolv.conf:

nameserver 127.0.0.11
options ndots:0

Once I echo nameserver x.x.x.x using the DNS IP of my VPN provider, I can now resolve hostnames and reach out to the internet: (new resolv.conf)

nameserver x.x.x.x

from docker-wireguard.

My config works, wg shows as connected, but it can't resolve any external hostnames until I edit the resolve.conf. Are there any log files in the container I can check?

I am running this on a Debian Buster host, just FYI

Here is my wg show output:

#> wg show
interface: wg0
public key: [REDACTED]
private key: (hidden)
listening port: 47663
fwmark: 0xca6c

peer: [REDACTED]
endpoint: [REDACTED]:2049
allowed ips: 0.0.0.0/0
latest handshake: 48 minutes, 29 seconds ago
transfer: 156 B received, 916 B sent

Here is my docker-compose:

---

version: "2.3"
services:
wireguard:
image: linuxserver/wireguard
container_name: wireguard
restart: unless-stopped
cap_add:
- NET_ADMIN
- SYS_MODULE
volumes:
- "/docker_config/wireguard/config:/config"
- "/lib/modules:/lib/modules"
environment:
- PGID=1001
- PUID=1001
- TZ=America/Chicago
ports:
- "51820:51820/udp"
sysctls:
- net.ipv4.conf.all.src_valid_mark=1

And here is my wg0.conf:

[Interface]
PrivateKey = [REDACTED]
Address = [REDACTED]/32
DNS = [REDACTED]

[Peer]
PublicKey = [REDACTED]
Endpoint = [REDACTED]:2049
AllowedIPs = 0.0.0.0/0

And lastly, here's the output from inside the container running wg-quick up /config/wg0.conf

/# wg-quick up /config/wg0.conf
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add [REDACTED]/32 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
sysctl: setting key "net.ipv4.conf.all.src_valid_mark": Read-only file system
[#] iptables-restore -n

from docker-wireguard.

In your logs it says:
sysctl: setting key "net.ipv4.conf.all.src_valid_mark": Read-only file system

You need to run the container in privileged mode. add "privileged: true" to your compose file:
wireguard:
image: linuxserver/wireguard
privileged: true
...

This is how i got mine to work at least.

from docker-wireguard.

so there still no solution to this problem?
I used the example docker compose from the repo,

Added one peer

allowed ips: 0.0.0.0/0 - cant connect to network, nor external nor internal/local.

What else can i do? How to resolve this?

from docker-wireguard.

Well, your log revealed a typo /var/run/s6/etc/cont-init.d/30-config: line 163: [: !-f: unary operator expected 😂 so thanks for that, but probably unrelated.

You need to check the handshake on the wireguard server to make sure the request reached the destination. Otherwise, all requests would be going to the ether and the client wouldn't know.

If the dns entry is not correct (or not reachable), you can have that behavior.

from docker-wireguard.

@aptalca haha nice!

I don't think it's an issue with the config, as everything works as expected on the host.
Here is the status of wg on the server, looks like it hasn't seen a handshake in a while.

interface: wg0
  public key: 5txxxx
  private key: (hidden)
  listening port: 49161

peer: qnVxxx
  preshared key: (hidden)
  endpoint: 157.xxx:34925
  allowed ips: 10.66.66.2/32, fd42:42:42::2/128
  latest handshake: 33 minutes, 9 seconds ago
  transfer: 32.18 KiB received, 69.38 KiB sent

Just checked the container again and it looks like it may be having trouble now?

root@93cb4b2483fc:/# wg
interface: wg0
  public key: qnVxxx
  private key: (hidden)
  listening port: 36650
  fwmark: 0xca6c

peer: 5txxxx
  preshared key: (hidden)
  endpoint: 198.xxx:49161
  allowed ips: 0.0.0.0/0, ::/0

from docker-wireguard.

It's possible it was showing funky info because I had just tried it on the host... maybe the container isn't even able to make the handshake. I just rebooted it and am not seeing anything about it

This is from the container

root@93cb4b2483fc:/# wg
interface: wg0
  public key: qnVxxx
  private key: (hidden)
  listening port: 40762
  fwmark: 0xca6c

peer: 5txxxx
  preshared key: (hidden)
  endpoint: 198.xxx:49161
  allowed ips: 0.0.0.0/0, ::/0

from docker-wireguard.

When you have it in client mode, there isn't much we can control. It all depends on your server settings and the conf you're using.

I do test this with a mullvad conf to connect to their servers and everything works fine.

from docker-wireguard.

Hmm, I guess it could be my server config. Would you mind taking a look at it? I just don't know why it would only struggle to connect from inside a container...

[Interface]
Address = 10.66.66.1,fd42:42:42::1/64
ListenPort = 49161
PrivateKey = uL3xxx
PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE; ip6tables -A FORWARD -i wg0  -j ACCEPT; ip6tables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE; ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o eth0 -j MASQUERADE

[Peer]
PublicKey = qnVxxx
PresharedKey = 5jxxxx
AllowedIPs = 10.66.66.2/32,fd42:42:42::2/128

from docker-wireguard.

127.0.0.11 is the docker dns resolver. If you're using the official docker install on a supported platform, and not manually modified any dns settings or iptables, that address should resolve hostnames within the same docker network and anything else should be forwarded upstream to the host's dns.

from docker-wireguard.

I am aware, but I am using wireguard to connect to an external VPN provider. I am using the latest image of this container and no modifications done.

When I get into the container and wg isn't connected and run curl ifconfig.co, it resolves and returns a response no problem. Once wg-quick up connects, I can run the same command and:

curl: (6) Could not resolve host: ifconfig.co

from docker-wireguard.

Oh, nevermind my previous response then. I got thrown off because you were talking about resolv.conf

When wg runs, (depending on your config) it should send everything through the tunnel so it doesn't matter what's in resolv.conf.

Also, you're saying you don't have modifications but that doesn't mean much because in client mode, we don't provide any default configs, you provide them all. So check your config, make sure your dns is defined and is accessible through the tunnel.

from docker-wireguard.

I have the same issue here.
I manage it by manually install openresolv (instead of resolvconf).

I will try to build a docker with it, and if it's work, propose a PR.

from docker-wireguard.

@SabatierBoris I tried your PR and didn't help my situation. Wireguard still cannot connect to my server from inside the container.

from docker-wireguard.

Hi @diericx, I had the same issue like you , client and server showed connected but no internet access inside vpn container. I had privateKey from another client IP address. If you have more clients, there must be for one IP exact privateKey. Maybe it will help.

from docker-wireguard.

@Krettoss thanks for the tip! I actually ended up ditching this idea and am running WG on the host, routing only traffic from the container through the WG connection via iptables config on UP and DOWN. Kind of don't want to mess with it anymore tbh, but documented it here if anyone want's to see how thats done.

from docker-wireguard.

You do not need privileged. That log message is fine and is expected. You're supposed to set the sysctl in the docker arguments.

from docker-wireguard.

You do not need privileged. That log message is fine and is expected. You're supposed to set the sysctl in the docker arguments.

Oh.. strange..
Im using this docker image: dyonr/qbittorrentvpn
Very rough image but i managed to kick it up with some tweaks, of which the privileged was required.

from docker-wireguard.

The same thing just started happening for my Docker container yesterday, even though it was working fine for months. 🤔

Just adding a note for those who try to add 0.0.0.0/0 as an allowed IP.

This seems to result in this same exception but I am finding success using

0.0.0.0/1

Try that.. see if it solve the issue for you all

That's not correct... 0.0.0.0/1 will only route 0.0.0.1 to 127.255.255.254 through the VPN. Any IPs higher than 127.255.255.254 won't go via the VPN.

from docker-wireguard.

You're commenting on a 1y+ closed posted. Open a new issue.

from docker-wireguard.

Another 1 year has passed and I have the same problem.

from docker-wireguard.

Another 1 year has passed and I have the same problem.

forget about this "Italian hand gesture". this blud created a great script, everything works. https://github.com/Nyr/wireguard-install

I just created a lxc in proxmox and installed the thing using the script, all is good.

full video by this blud
https://www.youtube.com/watch?v=er01qTRwqEo&t=403s

from docker-wireguard.

For routing other Docker containers via the VPN, I switched to Gluetun. It works very well for that use case. https://github.com/qdm12/gluetun

from docker-wireguard.