Hi again,
So wouldent it make sense if i used rules, that only allowed traffic through that specific IP address? The address is the 2.nd one, i wrote to you.
The ruleset using the 2nd address x.y.23.79 would be as follows:
[Enable] [Name] [Dest IP Start] [Dest IP End] [Protocol] [Dest Port Start] [Dest Port End]
Checked syno1 0.0.0.0 255.255.255.255 TCP 0 65535
Checked syno2 0.0.0.0 x.y.23.78 UDP 0 65535
Checked syno3 x.y.23.79 x.y.23.79 UDP 0 1193
Checked syno4 x.y.23.79 x.y.23.79 UDP 1195 65535
Checked syno5 x.y.23.80 255.255.255.255 UDP 0 65535But I don't think it's a good choice to work with this single address because VPN connection setup will fail if your VPN provider changes this address. In this case you would have to figure out which new set of addresses is valid, pick one of them and then adapt your ruleset to this new address. I think this is not what you want, but of course it's your choice.
I Could track the activity with tcpdump but now it seems unnecessary.. right?
Not really, because it would be interesting to figure out why VPN connection setup fails if you use a hostname instead of an IP address in your NAS's VPN profile.
But I think I know the reason, and if I'm right a packet trace isn't needed.
Here is my theory:
If you use a hostname in your VPN profile, the VPN client first has to resolve this name via DNS into IP addresses. Of course this name resolves into the four well known IP addresses (you could check this via the Windows nslookup command or the Linux dig command). And no matter if these addresses will change, what remains constant is the VPN profile's hostname which always resolves into the four IP addresses actually valid. The advantage of using four addresses (from the point of view of your VPN provider) is that the sequence these addresses are presented in the DNS reply will change in a round robin manner so you always use another address for any new VPN connection setup. The result is a kind of load balancing the work load of many VPN connections from different customers among those four VPN servers.
My assumption is, that this DNS resolution fails even if your DIR-655 is working as a DNS relay, because the 8th filter rule in my last post (Checked syno8 x.y.23.128 255.255.255.255 UDP 0 65535) will drop DNS requests to port 53/udp at 192.168.1.1 (your router's LAN address). If so this would really be a poor filter implementation because I would expect that only traffic forwarded to the Internet via the WAN interface is subject to filtering but not any traffic sent to the router's LAN side address only.
Hence following this theory we would have to complement the ruleset in order to allow 53/udp traffic sent from your NAS to your router's LAN address 192.168.1.1.
Unfortunately we can't do that, because the maximum of 8 filters is already reached, so we can't add any additional ones. Hence we have to summarize the two /26 ranges x.y.6.0 - x.y.6.63 and x.y.23.64 - x.y.23.127 to a single range x.y.6.0 - x.y.23.127 (which amounts to 4480 addresses instead of 2x64=128 addresses). But since your VPN provider might also change to addresses even outside this bigger range, I would recommend to work with the maximum range x.y.0.0 - x.y.255.255 of 65536 addresses that belong to your VPN provider.
So I would ask you to return to the original VPN profile using the hostname and try the following ruleset:
[Enable] [Name] [Dest IP Start] [Dest IP End] [Protocol] [Dest Port Start] [Dest Port End]
Checked syno1 0.0.0.0 192.167.255.255 TCP 1 65535
Checked syno2 192.169.0.0 255.255.255.255 TCP 1 65535
Checked syno3 0.0.0.0 x.y-1.255.255 UDP 1 65535
Checked syno4 x.y.0.0 x.y.255.255 UDP 1 1193
Checked syno5 x.y.0.0 x.y.255.255 UDP 1195 65535
Checked syno6 x.y+1.0.0 192.167.255.255 UDP 1 65535
Checked syno7 192.169.0.0 255.255.255.255 UDP 1 65535This ruleset restricts your NAS to talk to 1194/udp at any possible VPN provider address lying in the range x.y.0.0 - x.y.255.255. In addition your NAS may talk TCP and UDP to any local (!) IP address lying in the range 192.168.0.0 - 192.168.255.255 including DNS requests using 53/udp or 53/tcp. Choosing the complete range 192.168.0.0/16 gives you the freedom to renumber your network to any new range 192.168.x.0/24 without adapting the ruleset.
PT