Gateway won't start (`/dev/net/tun` missing) — Synology — Knowledge Base — GateControl Home Gateway

In short: After a reboot of your Synology NAS (e.g. due to a power outage or a DSM update), the GateControl gateway container no longer starts. The cause is a missing /dev/net/tun device, because some Synology models do not load the required kernel module automatically at boot. The fix is a one-time task in the DSM Task Scheduler that loads the module on every start. A ready-made script is provided below.

Does this affect me?

This article is relevant for you if all of the following apply:

You run the GateControl Gateway as a Docker container on a Synology NAS with DSM 7.
The container worked fine until now, but no longer starts after a reboot of the NAS (power outage, DSM update, manual reboot).
A manual start of the container also fails.

The same cause and fix also apply to other TUN-based containers such as WireGuard or OpenVPN.

Symptoms

The container gatecontrol-gateway-gateway-1 is stopped after a reboot and cannot be started in Container Manager.
On start, a Docker error mentioning /dev/net/tun appears, e.g.:

error gathering device information while adding custom device "/dev/net/tun": no such file or directory

Over SSH on the NAS:

ls -l /dev/net/tun
# -> ls: cannot access '/dev/net/tun': No such file or directory

Quick diagnosis

ls -l /dev/net/tun
lsmod | grep -iw tun

If /dev/net/tun does not exist and lsmod is missing a line starting with tun → then this exact problem is the cause, and the fix below resolves it.

Note: If access to your NAS or other services runs through the GateControl Gateway, that path is unreachable while the gateway is stopped. In that case use direct access on the local network or the DSM web interface.

Cause

The GateControl Gateway uses a WireGuard connection. For this it needs the virtual network device /dev/net/tun, which is provided by the Linux kernel module tun.

On some Synology models this module is not loaded automatically at system start. As long as the NAS keeps running, however, a module that has been loaded once stays active — and the gateway runs flawlessly for months. Automatic updates merely swap out the container without rebooting the NAS, so /dev/net/tun is preserved.

Only on a real reboot of the NAS (power outage, DSM update, manual reboot) does the module disappear — and with it /dev/net/tun. The container can no longer find the device and fails to start. This explains why the problem often appears suddenly after a long uptime and does not affect every NAS (on some models another package, e.g. VPN Server, already loads the module).

Technical background: The GateControl Gateway uses the userspace variant wireguard-go. It needs no WireGuard kernel module (which Synology does not ship), but it does need the general TUN/TAP device /dev/net/tun.

Fix: load the TUN module automatically at start

We set up a task in the DSM Task Scheduler that loads the tun module as administrator (root) on every system start.

Why not an installable package? DSM 7 does not allow installing unsigned packages with root privileges. Loading a kernel module, however, requires root privileges. The Task Scheduler is the only path provided by Synology to run such a command as root at boot.

Step by step

Open Control Panel → Task Scheduler.
Create → Triggered Task → User-defined script.
General tab:
- Task: Load TUN at boot
- User: root
- Event: Boot-up
Task Settings tab → User-defined script field: Paste the content of the script load-tun.sh (see below).
Save with OK. DSM may ask for your DSM password to confirm — this is normal for tasks that run as root.
Select the new task and click Run. This loads the module immediately, without a reboot.

The script

#!/bin/sh
# Loads the TUN/TAP kernel module and provides /dev/net/tun.

# 1. Load module (modprobe first, otherwise locate and load directly)
modprobe tun 2>/dev/null \
  || insmod "$(find /lib/modules -name 'tun.ko*' 2>/dev/null | head -1)" 2>/dev/null

# 2. Abort if the module could not be loaded
if ! grep -q '^tun ' /proc/modules; then
    logger -t load-tun "ERROR: TUN module could not be loaded"
    exit 1
fi

# 3. Ensure the device node exists
[ -d /dev/net ]     || mkdir -p /dev/net
[ -c /dev/net/tun ] || mknod /dev/net/tun c 10 200
chmod 0666 /dev/net/tun
logger -t load-tun "/dev/net/tun is ready"

# 4. (Optional, GateControl only) Start the gateway container:
# /usr/local/bin/docker start gatecontrol-gateway-gateway-1

exit 0

💡 Tip for GateControl users: Remove the leading # on line 4 so the task also starts the gateway container directly after loading the module. Adjust the container name to your project name if needed.

Verify the result

After running the task (or after the next reboot), check:

ls -l /dev/net/tun
# expected: crw-rw-rw- 1 root root 10, 200 ... /dev/net/tun

lsmod | grep -iw tun
# expected: a line starting with "tun"

Then start the GateControl gateway container (Container Manager or docker start). It should now run as "Up / healthy" again.

Does this persist across the next reboot?

Yes. Because the task is set up as a "Boot-up" event, the module is loaded automatically on every system start. The problem does not recur — not even after the next power outage.

⚠️ Important: Do not disable or delete this task. Otherwise /dev/net/tun will be missing again after the next reboot.

FAQ: Frequently asked questions about the /dev/net/tun issue
Guide & script: Load the TUN module automatically (load-tun.sh)

Gateway won't start (`/dev/net/tun` missing) — Synology