Docker YML won't start, can't add route

[gsxryan]

I'm at a loss here, I got this working in my dev environment, but can't get it working in prod. Dev had the same error until i ran the container unconfined, and with AppArmor disabled. I know this is bad practice but just trying to figure out what's going on here

      - seccomp:unconfined

the cap_add was not enough, or so it seemed...

I still get the following error on container start in prod, and at first in dev;
ERROR vpn: cannot add route for interface: operation not supported: when adding route: {Ifindex: 3 Dst: ::/0 Src: <nil> Gw: <nil> Flags: [] Table: 51820 Realm: 0}

Using the following config:

services:
  gluetun:
    image: qmcgaw/gluetun
    cap_add:
      - NET_ADMIN
    security_opt:
      - seccomp:unconfined
    network_mode: bridge
    ports:
      - 8888:8888/tcp # HTTP proxy
      - 8388:8388/tcp # Shadowsocks
      - 8388:8388/udp # Shadowsocks
    volumes:
      - /mnt/gluetun:/gluetun
    environment:
      - LOG_LEVEL=debug
      # See https://github.com/qdm12/gluetun/wiki
      - VPNSP=mullvad
      - VPN_TYPE=wireguard
      - WIREGUARD_PRIVATE_KEY=OMMITED
      - WIREGUARD_ADDRESS=10.67.23.1/32

My netplan on Dev (working) is simple

etwork:
  ethernets:
    ens18:
      dhcp4: true
  version: 2

My netplan on Prod is a little more complicated (iscsi LUN plus WAN route)

network:
  ethernets:
#ISP1
    ens17:
      dhcp4: true
      dhcp6: no
      nameservers:
          addresses: [9.9.9.9, 8.8.8.8]
#ISCSI
    ens16:
            dhcp4: no
            addresses: [192.168.15.12/24]
            mtu: 9000
            dhcp6: no
            routes:
             - to: 192.168.15.0/24
               via: 192.168.15.13
  version: 2

[qdm12]

It says operation not supported so i don't think it's a matter of permission otherwise it would say permission denied. Now it looks like this is about adding the route for IPv6 ::0, maybe you don't have support for ipv6? Gluetun should autodetect ipv6 support, but maybe there is a bug in the autodetection. If you want to dig in the source code it's:

• IPv6 detection:

  gluetun/internal/wireguard/run.go

  Line 42 in ca82fcb

  doIPv6, err := w.isIPv6Supported()

• Adding ipv6 route:

  gluetun/internal/wireguard/run.go

  Line 108 in ca82fcb

  // requires net.ipv6.conf.all.disable_ipv6=0

[gsxryan]

Thanks Quentin. I tried taking out "IPV6: no". I'm not getting an IPV6 address, so it's still not working. I'm not sure if i have other controls on the OS blocking or if it's my router yet. In Dev I do have an IPV6 address, so i think you may be onto something. I don't really want to use IPV6 anyway, but i'd like to test it with a valid address if i can get one.

2021/12/28 13:12:23 INFO wireguard: Using userspace implementation since Kernel support does not exist
2021/12/28 13:12:23 INFO wireguard: Connecting to x.x.x.x
2021/12/28 13:12:23 ERROR vpn: cannot add route for interface: operation not supported: when adding route: {Ifindex: 2 Dst: ::/0 Src: <nil> Gw: <nil> Flags: [] Table: 51820 Realm: 0}
2021/12/28 13:12:23 INFO vpn: retrying in 15s
2021/12/28 13:12:23 ERROR wireguard: Failed to load updated MTU of device: failed to get MTU of TUN device: no such device
2021/12/28 13:12:29 INFO healthcheck: program has been unhealthy for 6s: restarting VPN
2021/12/28 13:12:38 INFO firewall: setting VPN connection through firewall...

To reproduce you can try disabling ipv6 in grub using the following line in ubuntu:

GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 maybe-ubiquity"

sudo update-grub
reboot

[gsxryan]

I have an IPV6 address now and it seems to work fine. Should I open an issue to track this bug?

[qdm12]

Definitely! Also I believe IPV6 is the retro-compatible variable for OPENVPN_IPV6, meaning it doesn't affect Wireguard. The Wireguard implementation tries to auto-detect IPv6 support. I wanted to add this autodetection feature for Openvpn too so better fix it first!

Now the autodetection detects IPv6 support if it finds any route within the IPv6 family (so with an IPv6 address). Did you have any such route (you can try with ip route)? I'm wondering how you could have IPv6 routes but not have support to add IPv6 routes 🤔