Linux Client fails to create iptables Masquerade rules in [Synology]

[zzecool]

Describe the problem

Running Native Linux Client version 0.27.5 in Synology.
The iptables version is :

iptables v1.8.3 (legacy): Couldn't load match comment':No such file or directory

and cant change.

---

The Client fails to address the Routes assigned to him either if it is network range or an exit node.
Dirty fix :

If i manual do :

sudo iptables -t nat -A POSTROUTING -o ovs_bond0 -d 192.168.1.0/24 -j MASQUERADE

I can have access to the 192.168.1.0/24 network

or

sudo iptables -t nat -A POSTROUTING -o ovs_bond0 -j MASQUERADE

If i want to make him an Exit node ( access to internet )

ovs_bond0 is my interface

---

Now for the FORWARD chain that the Native Client is tryhing to use, the Chain is doesnt exist, if i create it it fails on the next set of rules like this :

2024-05-13T17:12:11+03:00 ERRO client/firewall/create_linux.go:48: failed to create iptables manager: running [/sbin/iptables -t filter -C FORWARD -o wt0 -m mark --mark 0x000007e4 -j ACCEPT --wait]: exit status 2: iptables v1.8.3 (legacy): Couldn't load match `mark':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

2024-05-13T17:12:11+03:00 ERRO client/internal/engine.go:315: failed creating firewall manager: running [/sbin/iptables -t filter -C FORWARD -o wt0 -m mark --mark 0x000007e4 -j ACCEPT --wait]: exit status 2: iptables v1.8.3 (legacy): Couldn't load match `mark':No such file or directory

Try `iptables -h' or 'iptables --help' for more information.

Not only that but there is a mechanism that deletes the FORWARD chain after a while. So maybe the proper appoach would be to check if iptables is iptables v1.8.3 (legacy) and the system is Synology and use the dirty way on the POSTROUTING chain that exists.

for identifying Synology you can use something like this :

# Check script is running on a Synology NAS
if ! /usr/bin/uname -a | grep -i synology >/dev/null; then
    echo "This script is NOT running on a Synology NAS!"
    echo "Copy the script to a folder on the Synology"
    echo "and run it from there."
    exit 1  # Not a Synology NAS
fi

# Get NAS model
model=$(cat /proc/sys/kernel/syno_hw_version)
#modelname="$model"

# Show script version
#echo -e "$script $scriptver\ngithub.com/$repo\n"
echo "$script $scriptver"

# Get DSM full version
productversion=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION productversion)
buildphase=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION buildphase)
buildnumber=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION buildnumber)
smallfixnumber=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION smallfixnumber)
majorversion=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION majorversion)
minorversion=$(/usr/syno/bin/synogetkeyvalue /etc.defaults/VERSION minorversion)

# Show DSM full version and model
if [[ $buildphase == GM ]]; then buildphase=""; fi
if [[ $smallfixnumber -gt "0" ]]; then smallfix="-$smallfixnumber"; fi
echo -e "$model DSM $productversion-$buildnumber$smallfix $buildphase\n"

# Print all the results at the end
echo "Model: $model"
echo "DSM Full Version: $productversion-$buildnumber$smallfix $buildphase"
echo "Major Version: $majorversion"
echo "Minor Version: $minorversion"

Another hint is that WGeasy works out of the box even as docker ( bridge mode )

With the following rules :

$ sudo iptables -L -v -n --line-numbers | grep 172.17.0.22     #( wgeasy ip )

Chain DOCKER
43       0     0 ACCEPT     udp  --  !docker0 docker0  0.0.0.0/0            172.17.0.22          udp dpt:51820

sudo iptables -t nat -L | grep 172.17.0.22     #( wgeasy ip )

Chain DEFAULT_POSTROUTING
MASQUERADE  udp  --  172.17.0.22          172.17.0.22          udp dpt:51820
DNAT       udp  --  anywhere             anywhere             udp dpt:51820to:172.17.0.22:51820

Cause in the config we have : AllowedIPs = 0.0.0.0/0

That way client can decide what networks he will route to, as 0.0.0.0/0 is allowed.

[zzecool]

It will be best for a Dev to actually try SYnology on his self to verify everything related.

For that task he can easily use this : https://github.com/vdsm/virtual-dsm

This is a virtual Synology Server running isolated in Docker, so you can test anything you want about itables without any fear of breaking the machine.

You may hijack the mechanism that handles the iptables, or find other more clever way.

Fingers crossed.

[mlsmaycon]

Hello @zzecool thanks for reporting this issue and sharing the virtual dsm project. We will have a look at it and report soon.

[mlsmaycon]

Actually, can you confirm if it works on userspace mode too? see steps to enabled here: #1983 (comment)

[zzecool]

Hello @zzecool thanks for reporting this issue and sharing the virtual dsm project. We will have a look at it and report soon.

@mlsmaycon Yes that will be great. The underlying mechanism in Synology not only deleting the FORWARD chain, it flushes every rule that has been added manually not by using their GUI firewall rule. The think is that this tool is useless for our case as it doesnt support masquerade etc.

Lets hope for a clean solution but a dirty will also be acceptable.

[seehma]

Hi, this ticket is now one month old. was there any progress? we also have a similar usecase and it would be cool to make it via our internal syno nas. regards m.

[fear]

+1 from me :). Having the same Problem