Using the OpenVPN TAP Interface on Synology NAS (Certificate Authenticated)


The joy of the OpenVPN package for Synology NAS was quickly gone. The attempt to set up a network for a small office ended almost without beginning. The interface for configuring the package did not have all the charms of this package itself (only authorization by login and password is available).

Recently I came across an article: "We teach NAS Synology to route traffic to the OpenVPN tunnel with certificate authentication . "
It seems to be what we need. But!
As it turned out, even such “hands-on” intervention in the bowels of the firmware does not allow raising connections through TAP interfaces.
Well. Do not stop halfway ...

The essence of the problem

If you do everything, as indicated in the article mentioned above, only with the type of TAP adapter, then we will get the following effect:

1. Select a VPN connection, click connect.
2. In the SSH session, we see that the tunnel has risen, the server is responding, data is coming. But the Synology interface tells us that “Connecting” is happening.
3. After 15-20 seconds, the interface politely informs that it failed to connect, and closes the working connection.

A detailed study of what was happening revealed that in all the device’s scripts, algorithms for determining the status of an OpenVPN connection are prescribed, based on the fact that they can only be TUN.

This is also evidenced by all the comments in the scripts.


At the time of writing, DMS 5.0-4493 Update 1 firmware was installed on the device.
Accordingly, everything described here is relevant for it .

For the convenience of managing scripts, it was decided to store everything on the admin network share.

We create the OpenVPN folder on it, it will

contain everything necessary for the client to work: 1. OpenVPN configuration file “tap.conf”:

dev tap
proto udp  
remote ServerIP 444
ns-cert-type server 
ca key/ca.crt  
cert key/Client1.crt  
key key/Client1.key  
comp-lzo yes 
tun-mtu 1500
tun-mtu-extra 32  
mssfix 1450
ping-restart 12  
ping 3
status log/openvpn-status.log  
log log/openvpn.log
script-security 2

2. Folder with certificates: "key"
3. Folder with logs: "log"
4. Scripts to start / stop VPN. (tunnel start):

KERNEL_MODULES="x_tables.ko ip_tables.ko iptable_filter.ko nf_conntrack.ko nf_defrag_ipv4.ko nf_conntrack_ipv4.ko nf_nat.ko iptable_nat.ko ipt_REDIRECT.ko xt_multiport.ko xt_tcpudp.ko xt_state.ko ipt_MASQUERADE.ko tun.ko"
# Make device if not present (not devfs)
if [ ! -c /dev/net/tun ]; then
  	# Make /dev/net directory if needed
  	if [ ! -d /dev/net ]; then
    		mkdir -m 755 /dev/net
  	mknod /dev/net/tun c 10 200
/usr/syno/bin/iptablestool --insmod $SERVICE ${KERNEL_MODULES}
echo "Starting openvpn client..."
/usr/sbin/openvpn --daemon --cd ${CONF_DIR} --config ${OPENVPN_CONF} --writepid /var/run/ (tunnel stop):

echo "Kill openvpn client..."
/bin/kill `cat /var/run/` 2>/dev/null (restarting the tunnel if the server is not available):

ping -c 3 
if [ $? -ne 0 ]; then
	echo "Stoping VPN.."
	echo "Sleep 5."
	sleep 5
	echo "Start...."

In general, this is enough.

As tests have shown, the VPN successfully restarts automatically when the Internet or remote server is disconnected. The OnLine script was written more to automatically start a VPN along with the NAS. But the full-time scheduler allows you to add script execution "every hour", so I added an availability check.

With this implementation, the NAS firmware has no idea about the tunnel (it’s for the better), but at the same time all the resources of the remote network are available (network backup to IP from the VPN goes fine).

Also popular now: