Skip to content

feat(netlink): detect ipv6 support level#2523

Open
qdm12 wants to merge 2 commits intomasterfrom
ivp6-level
Open

feat(netlink): detect ipv6 support level#2523
qdm12 wants to merge 2 commits intomasterfrom
ivp6-level

Conversation

@qdm12
Copy link
Copy Markdown
Owner

@qdm12 qdm12 commented Oct 14, 2024

Run it using image tag :pr-2523. You can configure the new option IPV6_CHECK_ADDRESSESES if you want, it defaults to [2001:4860:4860::8888]:53,[2606:4700:4700::1111]:53. You might want to run with LOG_LEVEL=debug to see what's going on with regards to IPv6.

there are 3 levels of ipv6 support: not supported, supported, and internet.

Supported means your kernel supports IPv6, but it cannot reach the internet over IPv6.

The logic for now is:

  • 'supported' if one ipv6 route is found that is not loopback
  • 'internet' if one default ipv6 route is found AND reaching a specified ipv6:port over TCP works outside the VPN

Gluetun has a new firewall setup where a query to is temporarily allowed through the firewall at container start, only to the IPv6 address/port combination to check for IPv6 support.

@diamkil
Copy link
Copy Markdown

diamkil commented Nov 11, 2024

I just tried this and the IPv6 detection does not seem to correctly work for me. I have some link-locals IPv6 but not a routable IPv6, yet it appears to detect IPv6 support as Internet.

========================================
========================================
=============== gluetun ================
========================================
=========== Made with ❤️ by ============
======= https://github.com/qdm12 =======
========================================
========================================

Running version pr-2523 built on 2024-10-15T13:27:08.150Z (commit 8c28d9e)

📣 All control server routes will become private by default after the v3.41.0 release

🔧 Need help? ☕ Discussion? https://github.com/qdm12/gluetun/discussions/new/choose
🐛 Bug? ✨ New feature? https://github.com/qdm12/gluetun/issues/new/choose
💻 Email? quentin.mcgaw@gmail.com
💰 Help me? https://www.paypal.me/qmcgaw https://github.com/sponsors/qdm12
2024-11-11T20:11:55Z INFO [routing] default route found: interface eth0, gateway 172.25.0.1, assigned IP 172.25.0.2 and family v4
2024-11-11T20:11:55Z INFO [routing] default route found: interface eth0, gateway fd34:5678:9abc::1, assigned IP fd34:5678:9abc::2 and family v6
2024-11-11T20:11:55Z INFO [routing] local ethernet link found: eth0
2024-11-11T20:11:55Z INFO [routing] local ipnet found: 172.25.0.0/16
2024-11-11T20:11:55Z INFO [routing] local ipnet found: fd34:5678:9abc::/64
2024-11-11T20:11:55Z INFO [routing] local ipnet found: fe80::/64
2024-11-11T20:11:55Z INFO [firewall] enabling...
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --policy INPUT DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --policy OUTPUT DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --policy FORWARD DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --policy INPUT DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --policy OUTPUT DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --policy FORWARD DROP
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append INPUT -i lo -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i lo -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o lo -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o lo -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o eth0 -s 172.25.0.2 -d 172.25.0.0/16 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -d ff02::1:ff00:0/104 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -s fd34:5678:9abc::2 -d fd34:5678:9abc::/64 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -s fd34:5678:9abc::2 -d fe80::/64 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/iptables --append INPUT -i eth0 -d 172.25.0.0/16 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i eth0 -d fd34:5678:9abc::/64 -j ACCEPT
2024-11-11T20:11:55Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i eth0 -d fe80::/64 -j ACCEPT
2024-11-11T20:11:55Z INFO [firewall] enabled successfully
2024-11-11T20:11:57Z INFO [storage] merging by most recent 20553 hardcoded servers and 20553 servers read from /gluetun/servers.json
2024-11-11T20:11:58Z DEBUG [netlink] IPv6 is supported by link eth0
2024-11-11T20:11:58Z DEBUG [netlink] IPv6 is supported by link eth0
2024-11-11T20:11:58Z DEBUG [netlink] IPv6 internet access is enabled on link eth0

ip route on the host has a default route
ip -6 route on the host has no default route

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Nov 15, 2024

@diamkil thanks for trying this out! 💯

Can you try docker pull qmcgaw/gluetun:pr-2523 and restart the gluetun container to see what debug logs it produces? I've added:

  • in d7f047e a debug log of each route being checked for IPv6
  • a possible fix to skip IPv4 routes properly in 22be52e

Thank you!!

@diamkil
Copy link
Copy Markdown

diamkil commented Nov 15, 2024

Here's the logs of the new version!

========================================
=============== gluetun ================
========================================
=========== Made with ❤️ by ============
======= https://github.com/qdm12 =======
========================================
========================================

Running version pr-2523 built on 2024-11-15T15:43:42.025Z (commit 5cec3c0)

📣 All control server routes will become private by default after the v3.41.0 release

🔧 Need help? ☕ Discussion? https://github.com/qdm12/gluetun/discussions/new/choose
🐛 Bug? ✨ New feature? https://github.com/qdm12/gluetun/issues/new/choose
💻 Email? quentin.mcgaw@gmail.com
💰 Help me? https://www.paypal.me/qmcgaw https://github.com/sponsors/qdm12
2024-11-15T21:57:47Z INFO [routing] default route found: interface eth0, gateway 172.25.0.1, assigned IP 172.25.0.2 and family v4
2024-11-15T21:57:47Z INFO [routing] default route found: interface eth0, gateway fd34:5678:9abc::1, assigned IP fd34:5678:9abc::2 and family v6
2024-11-15T21:57:47Z INFO [routing] local ethernet link found: eth0
2024-11-15T21:57:47Z INFO [routing] local ipnet found: 172.25.0.0/16
2024-11-15T21:57:47Z INFO [routing] local ipnet found: fd34:5678:9abc::/64
2024-11-15T21:57:47Z INFO [routing] local ipnet found: fe80::/64
2024-11-15T21:57:47Z INFO [firewall] enabling...
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --policy INPUT DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --policy OUTPUT DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --policy FORWARD DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --policy INPUT DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --policy OUTPUT DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --policy FORWARD DROP
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append INPUT -i lo -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i lo -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o lo -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o lo -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append OUTPUT -o eth0 -s 172.25.0.2 -d 172.25.0.0/16 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -d ff02::1:ff00:0/104 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -s fd34:5678:9abc::2 -d fd34:5678:9abc::/64 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append OUTPUT -o eth0 -s fd34:5678:9abc::2 -d fe80::/64 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/iptables --append INPUT -i eth0 -d 172.25.0.0/16 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i eth0 -d fd34:5678:9abc::/64 -j ACCEPT
2024-11-15T21:57:47Z DEBUG [firewall] /sbin/ip6tables --append INPUT -i eth0 -d fe80::/64 -j ACCEPT
2024-11-15T21:57:47Z INFO [firewall] enabled successfully
2024-11-15T21:57:49Z INFO [storage] merging by most recent 20776 hardcoded servers and 20553 servers read from /gluetun/servers.json
2024-11-15T21:57:49Z DEBUG [netlink] Checking route (link eth0): netlink.Route{LinkIndex:122, Dst:netip.Prefix{ip:netip.Addr{addr:netip.uint128{hi:0xfd3456789abc0000, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0xc0000ea228)}}, bitsPlusOne:0x41}, Src:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(nil)}}, Gw:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(nil)}}, Priority:256, Family:10, Table:254, Type:1}
2024-11-15T21:57:49Z DEBUG [netlink] IPv6 is supported by link eth0
2024-11-15T21:57:49Z DEBUG [netlink] Checking route (link eth0): netlink.Route{LinkIndex:122, Dst:netip.Prefix{ip:netip.Addr{addr:netip.uint128{hi:0xfe80000000000000, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0xc0000ea228)}}, bitsPlusOne:0x41}, Src:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(nil)}}, Gw:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(nil)}}, Priority:256, Family:10, Table:254, Type:1}
2024-11-15T21:57:49Z DEBUG [netlink] IPv6 is supported by link eth0
2024-11-15T21:57:49Z DEBUG [netlink] Checking route (link eth0): netlink.Route{LinkIndex:122, Dst:netip.Prefix{ip:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0xc0000ea228)}}, bitsPlusOne:0x1}, Src:netip.Addr{addr:netip.uint128{hi:0x0, lo:0x0}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(nil)}}, Gw:netip.Addr{addr:netip.uint128{hi:0xfd3456789abc0000, lo:0x1}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0xc0000ea228)}}, Priority:1024, Family:10, Table:254, Type:1}
2024-11-15T21:57:49Z DEBUG [netlink] IPv6 internet access is enabled on link eth0

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Nov 16, 2024

Thanks! It looks like the last route checked as a destination ::0 "unspecified", which is usually for default routes. But given my debug logs are rather hard to read (whoops, I should had wrote a little helping formatting code), what do you get from:

docker run --rm alpine:3.20 ip -6 route show table all

To find out why the heck that ::0 destination route is present, but not really the "internet" route.

@diamkil
Copy link
Copy Markdown

diamkil commented Nov 16, 2024

Here's the results of
docker run --network=gluetun_network --rm alpine:3.20 ip -6 route show table all (Using the same network as the gluetun container):

fd34:5678:9abc::/64 dev eth0  metric 256
fe80::/64 dev eth0  metric 256
default via fd34:5678:9abc::1 dev eth0  metric 1024
local ::1 dev lo table local  metric 0
local fd34:5678:9abc::b dev eth0 table local  metric 0
local fe80::42:acff:fe19:b dev eth0 table local  metric 0
multicast ff00::/8 dev eth0 table local  metric 256

Start of my docker network inspect gluetun_network

"Name": "gluetun_network",
"Scope": "local",
"Driver": "bridge",
"EnableIPv6": true,
"IPAM": {
    "Driver": "default",
    "Options": {},
    "Config": [
        {
            "Subnet": "172.25.0.0/16",
            "Gateway": "172.25.0.1"
        },
        {
            "Subnet": "fd34:5678:9abc::/64",
            "Gateway": "fd34:5678:9abc::1"
        }

Gateway is present but that's used to contact the host over IPv6, not sure if it's the network config that's problematic?

Just to be safe, here's the result of docker run --rm alpine:3.20 ip -6 route show table all (without the custom network specified):

fd12:3456:789a::/64 dev eth0  metric 256
fe80::/64 dev eth0  metric 256
default via fd12:3456:789a::1 dev eth0  metric 1024
local ::1 dev lo table local  metric 0
local fd12:3456:789a::242:ac11:3 dev eth0 table local  metric 0
local fe80::42:acff:fe11:3 dev eth0 table local  metric 0
multicast ff00::/8 dev eth0 table local  metric 256

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Nov 18, 2024

Thank you for the detailed investigation 💯
The responsible route triggering the "internet detected" is default via fd34:5678:9abc::1 dev eth0 metric 1024 (destination is default aka unspecified aka ::0). Unfortunately, cross comparing with my setup, I can't really tell just from ip routes if your have ipv6 internet access or not. One last thing to try:

docker run --rm alpine:3.20 ip a
docker run --rm alpine:3.20 ip -6 a

(referencing my previous comment):

So it seems you're right, the two factors indicating ipv6 support are inet6 fc00::242:ac11:2/7 scope global nodad (ipv6 address with scope global on default interface eth0) or/and default via fc00::1 dev eth0 metric 1024 pref medium (ipv6 route with default destination on default interface eth0). I can check for both in the code, but for now I limited it to find a default route for simplicity's sake.

@diamkil
Copy link
Copy Markdown

diamkil commented Nov 25, 2024

Sorry for the delay, here's the result of both commands:

docker run --rm alpine:3.20 ip a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
63: eth0@if64: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP
    link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fd12:3456:789a::242:ac11:3/64 scope global flags 02
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:3/64 scope link tentative
       valid_lft forever preferred_lft forever

docker run --rm alpine:3.20 ip -6 a

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 state UNKNOWN qlen 1000
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
65: eth0@if66: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 state UP
    inet6 fd12:3456:789a::242:ac11:3/64 scope global flags 02
       valid_lft forever preferred_lft forever
    inet6 fe80::42:acff:fe11:3/64 scope link tentative
       valid_lft forever preferred_lft forever

IPv6 seems to show scope global too, unfortunately.

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Dec 10, 2024

Sorry for the delay getting back; so clearly after comparing everything, there is no way to discern your routes/links from someone with full IPv6 support. As a consequence, if a default IPv6 route is found, then a final check dialing an IPv6 address (configurable, for now cloudflare.com IPv6 address) would be done, with the firewall only allowing output traffic to that address. I'm working on it, should be done around tomorrow!

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Dec 12, 2024

@diamkil when you have the time, can you try repulling qmcgaw/gluetun:pr-2523 and see how it does?
Now if a default non-loopback IPv6 route is found, gluetun allows through the firewall tcp output traffic only to the ipv6:port defined in IPV6_CHECK_ADDRESS (defaults to cloudflare.com [2606:4700::6810:84e5]:443, something that can be changed, happy to hear suggestions), and does a TCP dial to that ip:port. If it succeeds, then it's "ipv6 internet supported", otherwise it's just "ipv6 supported".

@qdm12 qdm12 force-pushed the ivp6-level branch 5 times, most recently from e3e6431 to f666713 Compare December 14, 2024 21:04
@Tuxie

This comment was marked as off-topic.

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Dec 27, 2024

@Tuxie your comment is rather irrelevant, so I've hidden it. This PR is about finding the IPv6 support level with LOG_LEVEL=debug (feel free to try and share those logs however), not about fixing other IPv6-related issues.

@qdm12 qdm12 added the Status: 🟡 Nearly resolved This might be resolved or is about to be resolved label Dec 27, 2024
@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Nov 7, 2025

Hey @diamkil ... a bit of one year later, but I'm about to merge this... if you get a few minutes, feel free to try it 😉

@pchristod
Copy link
Copy Markdown

pchristod commented Jan 23, 2026

Hey, I just came across this PR while trying to set up IPv6 with Gluetun & Synology host which unfortunately doesn't really allow Docker daemon.json modifications thus I can't set "experimental": true & "ip6tables": true to allow the correct routes for outgoing TCP traffic outside the VPN. This means I'm seeing the same issue as described in #1563 with Mullvad where the initial healthcheck will fail if it targets an IPv6 Server Endpoint. instead of IPv4.

I suppose the new detection logic would be pretty helpful in that case as it would fallback to 'supported' and not query the IPv6 Server Endpoint during initial startup but still support IPv6 inside the tunnel. I'm wondering if you still plan to merge it or if it needs additional testing? If so I'm guessing this branch is based on an older gluetun codebase and not the latest?

@Fethbita
Copy link
Copy Markdown

Fethbita commented Jan 23, 2026

I am also on Synology and have IPv6 disabled and ever since Gluetun v3.39.0 (I'm guessing it was OpenVPN version change from 2.5 to 2.6) Gluetun fails to connect, so I keep using v3.38.1 where there isn't this issue.
I hadn't realized this https://mullvad.net/en/blog/removing-openvpn-15th-january-2026

@qdm12 qdm12 force-pushed the master branch 2 times, most recently from d0247a1 to 0eeee5c Compare February 25, 2026 04:24
@qdm12 qdm12 added Priority: 🚨 Urgent Status: 📌 Before next release Has to be done before the next release labels Mar 7, 2026
@qdm12 qdm12 force-pushed the master branch 2 times, most recently from 2c06921 to 9a5995f Compare March 16, 2026 13:48
@qdm12 qdm12 force-pushed the ivp6-level branch 2 times, most recently from fc8ac5f to 30df034 Compare March 21, 2026 22:49
@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Mar 21, 2026

@pchristod I've updated the branch! I actually get the same problem with Mullvad since they have IPv6 servers, my container supports IPv6 but I did not configure my isp etc to support IPv6, so it does cycle through addresses until it reaches an IPv4 endpoint. This PR resolves this for me. See the PR description above on how to test it.

@diamkil feel free to re-test this if you have any comment on it, otherwise I'll merge it next week

@pchristod
Copy link
Copy Markdown

pchristod commented Mar 22, 2026

Hi @qdm12,

I've tried to test this, frist time trying a PR, so image tag :ipv6-level didn't work, had to get familiar first so I saw it is :pr-2523 instead. I've re-enabled net.ipv6.conf.all.disable_ipv6=0 and set WIREGUARD_ADDRESSES to both IPv4 and IPv6 on container level. On host level I didn't change any settings so Docker should be IPv4 only.
It seems to work with this tag as I didn't see any IPv6 connection attempts during startup and https://ipleak.net/ shows IPv6 is reachable and working, however compared to latest tag I get a lot of warnings I've not seen before:

2026-03-22T09:06:06+01:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-03-22T09:06:06+01:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv6 iptables failed: exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv6 iptables failed: exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [MTU discovery] reverting firewall changes: finding iptables chain rule line number: command failed: "/usr/sbin/iptables-legacy -t filter -L OUTPUT --line-numbers -n -v": exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-03-22T09:06:06+01:00 INFO [dns] DNS server listening on [::]:53
2026-03-22T09:06:07+01:00 INFO [dns] ready and using DNS server with dot upstream resolvers
2026-03-22T09:06:07+01:00 INFO [dns] downloading hostnames and IP block lists

as well as:

2026-03-22T09:06:06+01:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-03-22T09:06:06+01:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv6 iptables failed: exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv6 iptables failed: exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [iptables] restoring IPv4 iptables failed: exit status 1: iptables-restore: line 2 failed
2026-03-22T09:06:06+01:00 WARN [MTU discovery] reverting firewall changes: finding iptables chain rule line number: command failed: "/usr/sbin/iptables-legacy -t filter -L OUTPUT --line-numbers -n -v": exit status 4: Can't lock /run/xtables.lock: Resource temporarily unavailable
Another app is currently holding the xtables lock. Perhaps you want to use the -w option?
2026-03-22T09:06:06+01:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-03-22T09:06:06+01:00 INFO [dns] DNS server listening on [::]:53
2026-03-22T09:06:07+01:00 INFO [dns] ready and using DNS server with dot upstream resolvers
2026-03-22T09:06:07+01:00 INFO [dns] downloading hostnames and IP block lists

and

2026-03-22T09:06:06+01:00 WARN flushing conntrack failed: querying netlink request: netfilter query: netlink receive: invalid argument

I suppose these warnings are a result of running the container on a Synology (DS918+) host and missing implementations?

@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Mar 23, 2026

I suppose these warnings are a result of running the container on a Synology (DS918+) host and missing implementations?

Just that one WARN flushing conntrack failed: querying netlink request: netfilter query: netlink receive: invalid argument but it's fine, it's being worked on in another pr

The other errors you get, I will investigate! Do you get those same errors restoring IPv4 iptables failed on the latest image??

@pchristod
Copy link
Copy Markdown

Hi @qdm12

I've reverted to latest to check again. No, those errors are new, I just receive this one you mentioned is expected.

WARN flushing conntrack failed: querying netlink request: netfilter query: netlink receive: invalid argument

Thanks for following up 👍

qdm12 added 2 commits March 23, 2026 14:37
- 'supported' if one ipv6 route is found that is not loopback and not a default route
- 'internet' if one default ipv6 route is found
- If a default IPv6 route is found, query the ip:port defined by `IPV6_CHECK_ADDRESS` to check for internet access
@qdm12
Copy link
Copy Markdown
Owner Author

qdm12 commented Mar 23, 2026

Try pulling that image tag again (not :ipv6-level my bad by the way!), it should now log what data is failed to restore with. Run with FIREWALL_IPTABLES_LOG_LEVEL=debug as well, to see what commands it runs before it starts "throwing up"?

@pchristod
Copy link
Copy Markdown

pchristod commented Mar 24, 2026

Hi @qdm12

no worries :)
So I pulled the new image and tried it without that FIREWALL_IPTABLES_LOG_LEVEL=debug at first because I figured I'd give it a shot and set this option when it didn't work. What can I say, it didn't give any errors this time. Whatever you did it seemed to have worked 👍
I can see only the WARN which is expected, I've set net.ipv6.conf.all.disable_ipv6=0 and WIREGUARD_ADDRESSES to IPv4 and IPv6 as per Wiki and I have IPv6 connectivity inside the container as per https://ipleak.net/.

2026-03-24T16:14:55+01:00 INFO [routing] default route found: interface eth0, gateway 172.18.0.1, assigned IP 172.18.0.2 and family v4
2026-03-24T16:14:55+01:00 INFO [routing] local ethernet link found: eth0
2026-03-24T16:14:55+01:00 INFO [routing] local ipnet found: 172.18.0.0/16
2026-03-24T16:14:55+01:00 INFO [routing] local ipnet found: fe80::/64
2026-03-24T16:14:56+01:00 INFO [firewall] enabling...
2026-03-24T16:14:56+01:00 INFO [firewall] enabled successfully
2026-03-24T16:14:56+01:00 WARN flushing conntrack failed: querying netlink request: netfilter query: netlink receive: invalid argument

2026-03-24T16:19:25+01:00 INFO [vpn] wireguard setup is complete. Note wireguard is a silent protocol and it may or may not work, without giving any error message. Typically i/o timeout errors indicate the wireguard connection is not working.
2026-03-24T16:19:25+01:00 INFO [MTU discovery] finding maximum MTU, this can take up to 6 seconds
2026-03-24T16:19:26+01:00 INFO [MTU discovery] setting VPN interface tun0 MTU to maximum valid MTU 1380
2026-03-24T16:19:26+01:00 INFO [dns] DNS server listening on [::]:53
2026-03-24T16:19:26+01:00 INFO [dns] ready and using DNS server with dot upstream resolvers
2026-03-24T16:19:26+01:00 INFO [dns] downloading hostnames and IP block lists

It did connect to an IPv4 Endpoint immediately. You need to see any more Log Entries, I just copied the ones I thought would be enough?

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Priority: 🚨 Urgent Status: 📌 Before next release Has to be done before the next release Status: 🟡 Nearly resolved This might be resolved or is about to be resolved

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants