Repository navigation
[BUG] dns name resolution still broken after rebase #399
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
dns name resolution is currently not working, i presume every version after rebase is unusable.
and yes, i make this issue after "Fix breaking openresolv change" update, with did not help.
For now i have simply rolled back to "image: lscr.io/linuxserver/wireguard:1.0.20250521-r0-ls94" and that works fine.
Expected Behavior
No response
Steps To Reproduce
client mode
use it
fails, because it cannot solve dns.
Environment
- OS: linux
- How docker service was installed: docker composeCPU architecture
x86-64
Docker creation
Compose, if you made any big changes i dont see it on documentation.Container logs
Try again: `XXXXXXXX.XXXXXXXXX.com:PORT'. Trying again in 1.20 seconds... yea i removed relevant parts here.
Activity
github-actions commentedon Jan 10, 2026
Thanks for opening your first issue here! Be sure to follow the relevant issue templates, or risk having this issue marked as invalid.
Opalinus commentedon Jan 15, 2026
UPDATE2: Tested again after fixing routes and it works! see response of thespad
UPDATE: according to aptalca IPv6 is unsupported. So my case is expected to fail.
DNS resolve does not work for me with either:
"latest" nor "image: lscr.io/linuxserver/wireguard:1.0.20250521-r0-ls94"
Also my DNS is a IPv6 adress. Same config works with wg-quick tools though
**** Client mode selected. **** [custom-init] No custom files found, skipping... **** Disabling CoreDNS **** **** Found WG conf /config/wg_confs/wg_config.conf, adding to list **** **** Activating tunnel /config/wg_confs/wg_config.conf **** Warning:/config/wg_confs/wg_config.conf' is world accessible[#] ip link add dev wg_config type wireguard
[#] wg setconf wg_config /dev/fd/63
[#] ip -4 address add 192.168.178.111/24 dev wg_config
[#] ip -6 address add fdf4:f1f6:bcf3::207/64 dev wg_config
RTNETLINK answers: Network unreachable
[#] ip link set mtu 1420 up dev wg_config
[#] resolvconf -a wg_config -m 0 -x
[#] wg set wg_config fwmark 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] ip -4 route add 0.0.0.0/0 dev wg_config table 51820
[#] nft -f /dev/fd/63
**** All tunnels are now active ****
[ls.io-init] done`
LinuxServer-CI commentedon Feb 14, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
aptalca commentedon Feb 23, 2026
First poster didn't post enough info to go on.
The second poster is using ipv6, which is not something we support, and their dns is an ipv6 address.
The third poster didn't post any info.
We can't really help under these circumstances. I personally did a lot of testing with multiple VPSes and it all works fine for me.
thespad commentedon Feb 23, 2026
I have seen this issue, but only following a host reboot and it appears to be some kind of race condition causing it as a recreation of the container fixes the name resolution. I haven't been able to reliably replicate it outside of that and without additional troubleshooting data it's going to be hard to.
FWIW IPv6 should work, we just don't support it because we don't have the means to reliably test it - that said, based on your error the issue is not a DNS one but a routing one
RTNETLINK answers: Network unreachable.Opalinus commentedon Feb 23, 2026
tysm for taking the time properly answering me. I can confirm repairing the routes (with the help of my fave LLM) i got it: Running the container connects properly via IPv6 to my endpoint. I did not encounter the mentioned race-condition using my VPS virtbase.de
ZillaGit104 commentedon Mar 16, 2026
Withdrawing my issue. I had an entry point script that was causing issues. Mega apologies! No issues with DNS resolution using this container as a client.
LinuxServer-CI commentedon Apr 16, 2026
This issue has been automatically marked as stale because it has not had recent activity. This might be due to missing feedback from OP. It will be closed if no further activity occurs. Thank you for your contributions.
LinuxServer-CI commentedon Jul 16, 2026
This issue is locked due to inactivity