DB-유

Restricting Synology Access with Firewall Profiles by Country

· synology, firewall, security

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:5001 loads. 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.