Restricting Synology Access with Firewall Profiles by Country
Open the Auto Block list on any Synology exposed to the internet and the picture is always the same: hundreds of addresses, almost none from the country the users live in. The DSM firewall can filter by location, so if your users are in one or two countries, allow those and deny the rest. Most login attempts never reach the authentication layer. It doesn't replace strong passwords and 2-step verification, but it costs nothing.
I'll build a country-based profile on DSM 6.2 with a safe LAN rule in front. Have the firewall enabled already, list the countries your users connect from (including where they travel), and keep a way back in: RESET button access or a LAN client. I've needed both.
How location matching works
DSM ships a GeoIP database that maps address ranges to countries and updates it with DSM updates. When a rule uses Location as its source, the firewall resolves the source address against that database and matches if the country is in the rule's list. The match is at connection time, on IPv4 and IPv6. Accuracy is good at country level and poor for anything finer, which is why DSM only offers countries.
Rules are still evaluated top to bottom, first match wins, and the default action when nothing matches is set at the bottom of the rules dialog.
A dedicated profile
Control Panel → Security → Firewall → Firewall Profile → Manage (the dropdown arrow) → Create. Name it geo-restricted. Profiles let you keep the existing rule set intact and switch between them, which is useful for testing and for a quick revert.
Select the new profile and click Edit Rules. Because it starts empty, build it from scratch in this order.
Rule 1: LAN and VPN clients
Create → Ports: All → Source IP: Specific IP → Subnet 10.20.30.0/24 → Action: Allow. Add a second rule the same way for the VPN client range 10.99.0.0/24 if VPN Server is in use. These two rules guarantee that nothing below can lock out a local user, whatever the GeoIP database thinks about private ranges.
Rule 2: allowed countries, published services only
Create → Ports: Select from a list of built-in applications → tick the services you actually publish, for example DSM (HTTPS) 5001, Synology Drive Server 6690, VPN Server (OpenVPN) 1194. Source IP: Location → pick the countries, for example your own and the ones colleagues travel to. Action: Allow.
Keep the port selection tight. A country allow rule on "All ports" would open SSH or SMB from the whole country, which is not the intention.
Rule 3: Let's Encrypt
If the NAS renews a Let's Encrypt certificate, port 80 must be reachable from the validation servers, whose locations vary. Create → Ports: Custom → TCP 80 → Source IP: All → Allow. DSM's nginx only serves the ACME challenge path and a redirect on 80, so this is acceptable.
Rule 4: deny the rest
Create → Ports: All → Source IP: All → Action: Deny. Alternatively leave the rule out and set "If no rules are matched: Deny access" at the bottom of the dialog. I prefer the explicit rule because it is visible in the list and it is what people expect to see when reviewing the configuration.
The finished profile reads:
1. Allow All ports 10.20.30.0/24
2. Allow All ports 10.99.0.0/24
3. Allow 5001, 6690, 1194 Location: DE, AT, CH
4. Allow TCP 80 All
5. Deny All ports All
Applying it to the right interfaces
Firewall → Firewall Profile → select geo-restricted → Apply. Then check the interface dropdown at the top of the Edit Rules dialog. In DSM 6.2 the profile is applied per interface; rules under "All interfaces" apply everywhere, and rules under LAN 1 or a VPN interface apply there only. Put the whole set under All interfaces unless you have a reason to differentiate.
Testing it
- From the LAN, DSM stays reachable, which confirms rule 1.
- From a phone on mobile data in an allowed country,
https://nas.example.com:5001loads. From a VPN endpoint or a cloud VM in a country not in the list, the same URL times out; a cheap virtual machine in another region is the easiest way to test this. - Let
curl -I http://nas.example.com/from anywhere return a redirect, confirming rule 4. - After a day, Control Panel → Security → Auto Block → Block List should be much shorter, and Log Center → Connection logs should show failed logins only from allowed countries.
From the shell you can see the rules in iptables form:
sudo iptables -L FORWARD_FIREWALL -n -v | head -30
sudo iptables -L INPUT_FIREWALL -n -v | head -30
Geo rules appear as match-set entries referring to ipsets the firewall maintains per country.
Where it bites
- A legitimate user is blocked although their country is allowed. Their mobile carrier routes traffic through a gateway in another country, which is common for roaming and some ISPs. Ask them to visit an IP lookup site; if the country shown differs, add that country or have them use the VPN via a static allowed address.
- QuickConnect stops working after applying the profile. QuickConnect relays connect from Synology's servers; add the built-in application "QuickConnect" as an allow rule with Source All above the deny rule, or accept that QuickConnect relay is unavailable and use the DDNS name.
- Rules are applied but everything is still reachable from everywhere. The profile is applied to LAN 1 but the NAS is connected through LAN 2 or a bond. Check the interface dropdown and use All interfaces.
- After a DSM update the country list resolves differently and a previously allowed address is denied. The GeoIP database was updated. There is no manual update; if a specific address matters, add it as a Specific IP allow rule above the location rule.
It'll occasionally bite a travelling user. Still worth it: ten minutes of setup, and thousands of daily probes become a handful.