Using OpenVPN TAP Interface on Synology NAS (with certificate authentication)

Prehistory

The joy of the appearance of the OpenVPN package for network storage Synology quickly passed. An attempt to set up a network for a small office ended almost without a start. In the interface for setting the package, all the charms of this package itself were missing (only login and password authorization is available).

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

The essence of the problem

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

1. Choose a VPN connection, click to connect.
2. In the SSH session, we see that the tunnel is up, the server is pinged, the data is coming. But Synology's interface tells us what's going on.
3. After 15-20 seconds, the interface politely informs that it failed to connect, and closes the working connection.
')
A detailed study of what is happening revealed that in all the device scripts, algorithms are written to determine the status of an OpenVPN connection, based on the fact that they can only be TUN.

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

Solution to the problem

At the time of this writing, the device has DMS 5.0-4493 Update 1 firmware installed.
Accordingly, everything described here is relevant for her .

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

Create an 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 client tls-client 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 float 

2. Folder with certificates: "key"
3. Folder with logs: "log"
4. VPN start / stop scripts.

Start.sh (start tunnel):

 #!/bin/sh CONF_DIR="/volume1/adm/OpenVPN/" OPENVPN_CONF="tap.conf" 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" SERVICE="ovpnc" # 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 fi mknod /dev/net/tun c 10 200 fi /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/ovpn_client.pid 

Stop.sh (tunnel stop):

 #!/bin/sh echo "Kill openvpn client..." /bin/kill `cat /var/run/ovpn_client.pid` 2>/dev/null 

OnLine.sh (restarting the tunnel if the server is not available):

 #!/bin/sh ping -c 3 10.23.122.1 if [ $? -ne 0 ]; then echo "Stoping VPN.." sh Stop.sh echo "Sleep 5." sleep 5 echo "Start...." sh Start.sh fi 

In general, this is enough.

As shown by the tests, the VPN successfully restarts automatically when the Internet or remote server is disconnected. The OnLine script was written more to automatically start the VPN along with the NAS. But the regular scheduler allows you to add the execution of the script "every hour", so it added the availability check.

With this implementation, the NAS firmware does not have a clue about the tunnels (it is for the best), but all the resources of the remote network are available (network redundancy on the IP from the VPN passes perfectly).