Frequently Asked Questions (FAQ)

Frequently asked questions about the problem that the GateControl Gateway (or another TUN/VPN container) no longer starts on a Synology NAS after a reboot. For the full walkthrough, see the knowledge base article „GateControl Gateway no longer starts (/dev/net/tun missing)".

My gateway ran for months. Why does it suddenly fail after a power outage?

The required kernel module tun is not loaded automatically at boot on some Synology models. Once loaded, however, it stays active as long as the NAS keeps running. Automatic updates only swap out the container and do not reboot the NAS — that is why everything kept working. A power outage is often the first real reboot in a long time, and that is when the module (and with it /dev/net/tun) is lost.

How do I know this is exactly my problem?

Over SSH on the NAS:

ls -l /dev/net/tun      # "No such file or directory"
lsmod | grep -iw tun    # no line starting with "tun"

If both are true and the container fails to start with an error about /dev/net/tun, this is the problem.

Why is there no installable package for this in Package Center?

For security reasons, DSM 7 does not allow unsigned packages with root privileges. Loading a kernel module, however, requires root privileges. A normal package is therefore not technically possible. The Task Scheduler is the only path provided by Synology to run a root command at system start — which is why we solve it that way.

I don't have sudo / no root access. Does the fix still work?

Yes. You do not need sudo. The DSM Task Scheduler runs tasks created with the user root with the necessary privileges automatically. The entire setup is done through the DSM web interface.

Is loading the tun module safe?

Yes. tun (TUN/TAP) is a standard Linux kernel module shipped by Synology itself (/lib/modules/tun.ko). Every VPN solution needs it anyway. The script merely loads this already-present module — it does not install any third-party code into the kernel.

Do I have to run the script again after every reboot?

No. Because the task is set up as a "Boot-up" event, it runs automatically on every system start. Setting it up once is enough.

What does chmod 0666 on /dev/net/tun mean? Is that a security risk?

Those are the default permissions for this device (Linux creates it the same way: crw-rw-rw-). It matches the normal state and poses no additional risk.

When creating the task, DSM asks for my password / warns about root. Is that normal?

Yes. DSM points out that the task runs with root privileges and asks for your DSM password to confirm. This is the normal behavior for root tasks in the Task Scheduler — it is not the same as an unsafe package.

Can the same task also start the gateway container?

Yes. Remove the leading # on the last line of the script:

/usr/local/bin/docker start gatecontrol-gateway-gateway-1

Then, at boot, the task first loads the module and afterwards starts the container. Adjust the container name to your project name if needed.

After running it, /dev/net/tun is still not there. What now?

Check the system log (Log Center) for a message with the tag load-tun:

• "ERROR: TUN module could not be loaded" → On your model the tun module may not be included. Check:

  find /lib/modules -name 'tun.ko*'
  

  If this returns nothing, please contact our support with the output of uname -r and your NAS model.
• Also make sure the task was really created with the user root.

Does this affect only the GateControl Gateway?

No. Any Docker container that needs /dev/net/tun (e.g. WireGuard or OpenVPN) is equally affected on affected Synology models. The approach described here fixes the problem for all of these containers.

I already use Synology VPN Server. Do I still need the script?

Possibly not. Some packages such as VPN Server already load the tun module at start. After a reboot, check with lsmod | grep -iw tun. If the module is present, you do not need the script. If it is not, the script is still harmless (it does not reload an already-loaded module).