Synology has trouble accessing internet after enabling Gluetun

[moToroTor]

It's weird, but once I installed Gluetun the other container going through Gluetun is doing fine but I can't download other docker images or ping out.

docker pull ubuntu/ubuntu
Using default tag: latest
Error response from daemon: Get "https://registry-1.docker.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)

ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted

I thought things were weird when I got an e-mail from Synology about the connection to my DDNS being lost just after setting up gluetun. I am sure I'm missing something obvious but I can't find anything useful in the other discussions.

Oddly my SynoCommunity transmission install seems to still be working.

[moToroTor]

I rebooted the synology DS1815+ and it is now able to connect, but gluetun is now complaining a lot, and I understand I'm not supposed to make an issue I'm just expanding on this oddness.

|           ├── Block malicious: yes
|           ├── Block ads: no
|           ├── Block surveillance: no
|           └── Blocked IP networks:
|               ├── 127.0.0.1/8
|               ├── 10.0.0.0/8
|               ├── 172.16.0.0/12
|               ├── 192.168.0.0/16
|               ├── 169.254.0.0/16
|               ├── ::1/128
|               ├── fc00::/7
|               ├── fe80::/10
|               ├── ::ffff:127.0.0.1/104
|               ├── ::ffff:10.0.0.0/104
|               ├── ::ffff:169.254.0.0/112
|               ├── ::ffff:172.16.0.0/108
|               └── ::ffff:192.168.0.0/112
├── Firewall settings:
|   └── Enabled: yes
├── Log settings:
|   └── Log level: info
├── Health settings:
|   ├── Server listening address: 127.0.0.1:9999
|   ├── Target address: cloudflare.com:443
|   ├── Duration to wait after success: 5s
|   ├── Read header timeout: 100ms
|   ├── Read timeout: 500ms
|   └── VPN wait durations:
|       ├── Initial duration: 6s
|       └── Additional duration: 5s
├── Shadowsocks server settings:
|   └── Enabled: no
├── HTTP proxy settings:
|   └── Enabled: no
├── Control server settings:
|   ├── Listening address: :8000
|   └── Logging: yes
├── Storage settings:
|   └── Filepath: /gluetun/servers.json
├── OS Alpine settings:
|   ├── Process UID: 1000
|   └── Process GID: 1000
├── Public IP settings:
|   ├── Fetching: every 12h0m0s
|   ├── IP file path: /tmp/gluetun/ip
|   └── Public IP data API: ipinfo
└── Version settings:
    └── Enabled: yes
2024-09-01T04:49:27Z INFO [routing] default route found: interface eth0, gateway 172.17.0.1, assigned IP 172.17.0.3 and family v4
2024-09-01T04:49:27Z INFO [routing] adding route for 0.0.0.0/0
2024-09-01T04:49:27Z INFO [firewall] setting allowed subnets...
2024-09-01T04:49:27Z INFO [routing] default route found: interface eth0, gateway 172.17.0.1, assigned IP 172.17.0.3 and family v4
2024-09-01T04:49:27Z INFO TUN device is not available: open /dev/net/tun: no such file or directory; creating it...
2024-09-01T04:49:27Z INFO [dns] using plaintext DNS at address 1.1.1.1
2024-09-01T04:49:27Z INFO [http server] http server listening on [::]:8000
2024-09-01T04:49:27Z INFO [firewall] allowing VPN connection...
2024-09-01T04:49:27Z INFO [healthcheck] listening on 127.0.0.1:9999
2024-09-01T04:49:27Z INFO [wireguard] Using userspace implementation since Kernel support does not exist
2024-09-01T04:49:27Z INFO [wireguard] Connecting to 146.70.230.146:51820
2024-09-01T04:49:27Z INFO [wireguard] 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.
2024-09-01T04:49:27Z INFO [dns] downloading hostnames and IP block lists
2024-09-01T04:49:27Z INFO [healthcheck] healthy!
2024-09-01T04:49:34Z INFO [dns] DNS server listening on [::]:53
2024-09-01T04:49:37Z WARN [dns] exchanging over DoT connection: read tcp 10.2.0.2:42931->1.1.1.1:853: i/o timeout
2024-09-01T04:49:37Z WARN [dns] exchanging over DoT connection: read tcp 10.2.0.2:42932->1.1.1.1:853: i/o timeout
2024-09-01T04:49:46Z INFO [healthcheck] program has been unhealthy for 6s: restarting VPN
2024-09-01T04:49:46Z INFO [healthcheck] 👉 See https://github.com/qdm12/gluetun-wiki/blob/main/faq/healthcheck.md
2024-09-01T04:49:46Z INFO [healthcheck] DO NOT OPEN AN ISSUE UNLESS YOU READ AND TRIED EACH POSSIBLE SOLUTION
2024-09-01T04:49:46Z INFO [vpn] stopping
2024-09-01T04:49:46Z ERROR [vpn] getting public IP address information: fetching information: Get "https://ipinfo.io/": context canceled
2024-09-01T04:49:46Z ERROR [vpn] cannot get version information: Get "https://api.github.com/repos/qdm12/gluetun/commits": context canceled
2024-09-01T04:49:46Z ERROR [wireguard] Failed to load updated MTU of device: failed to get MTU of TUN device: no such device
2024-09-01T04:49:46Z INFO [vpn] starting
2024-09-01T04:49:46Z INFO [firewall] allowing VPN connection...
2024-09-01T04:49:46Z INFO [wireguard] Using userspace implementation since Kernel support does not exist
2024-09-01T04:49:46Z INFO [wireguard] Connecting to 146.70.230.146:51820
2024-09-01T04:49:46Z INFO [wireguard] 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.
2024-09-01T04:49:47Z WARN [dns] exchanging over DoT connection: read tcp 10.2.0.2:40463->1.0.0.1:853: i/o timeout
2024-09-01T04:49:47Z WARN [dns] exchanging over DoT connection: read tcp 10.2.0.2:40464->1.0.0.1:853: i/o timeout
2024-09-01T04:49:48Z WARN [dns] exchanging over DoT connection: read tcp 10.2.0.2:42957->1.1.1.1:853: i/o timeout

[moToroTor]

I did switch to an openvpn config and got that working, one issue is that you can't use the protonvpn option because the free servers aren't in the server list, I might suggest adding a protonvpn-free provider option. It's strange because wireguard worked earlier and then no longer worked. Also the big thing about how I had to reboot the device entirely to get networking on device working.