HomeLabFix

Reference diagnosis / Synology + Tailscale

Synology Tailscale Connected but NAS Is Unreachable

Separate tailnet connectivity, name resolution, the tailnet access policy, DSM firewall rules, and the exact Synology service port before changing the NAS.

A connected or visible Tailscale node does not prove that DSM, SMB, Synology Drive, or another service is listening on the port you are trying to use. Diagnose the tailnet path, hostname, exact service port, tailnet access policy, and DSM firewall as separate layers.[2][4][5][14]

Do not treat DSM 7 package restrictions as the default explanation for inbound access failures. Tailscale documents the DSM 7 limitation primarily for outbound Tailscale access from other applications running on the NAS.[1]

Applicability

Products
Synology DSM · Tailscale
Scope
Use this diagnosis when a Synology NAS running the Tailscale package appears connected or is expected in the tailnet, but DSM or another NAS service cannot be reached. The core Tailscale checks apply to the documented Synology package on DSM 6 and DSM 7. Management-port locations are version-specific, and this page cites separate DSM 6 and DSM 7 documentation; its DSM firewall procedure is verified against DSM 7 documentation only. The DSM 7 TUN procedure applies only to outbound connections from other applications on the NAS and requires Tailscale 1.22.2 or later.[1][12][13][11]
Version notes
  • DSM 6 (Tailscale package behavior and DSM 6 management-port UI)
  • DSM 7 (Tailscale package restrictions, firewall, and Login Portal UI)
  • Tailscale 1.22.2 or later (DSM 7 outbound TUN procedure only)
Last verified

Symptoms

  • The NAS appears in Tailscale status or the Machines page, but DSM or a package service does not open.[2][5]
  • The NAS answers a Tailscale path check, but the intended TCP service is unavailable.[2][4][14]
  • Access works with the NAS Tailscale IP but fails with its MagicDNS machine name.[2][9][10]

Quick diagnosis

Start with observation and read-only checks. Keep the exact service and port constant when comparing results.

Read-only

Record the Tailscale version

Check the client version before deeper diagnosis; Tailscale puts version verification first in its device-connectivity workflow.[2][5]

tailscale version
Read-only

Confirm the peer and tailnet

Run status on the client you are using. Confirm that the expected Synology node is listed and note its Tailscale IP and connection state.[2][5]

tailscale status
Safe network check

Test the Tailscale path by IP

Use the NAS Tailscale IP first. A successful default Tailscale ping shows that the peer answered Tailscale's DISCO connectivity check and reports the path it found; it does not prove that DSM or another application service is available.[2][4]

tailscale ping <nas-tailscale-ip>
Safe network check

Test the exact service and port

Identify the service you need and its configured port. The tailscale nc command opens a TCP connection to the specified host and port and connects it to standard input and output. The documentation does not define a literal SUCCESS message; any response after connection comes from the service on that port. Synology documents that DSM ports can be changed and packages use different ports.[2][3][12][13][14]

tailscale nc <nas-tailscale-ip> <port>
Safe network check

Compare IP and name

Try the same service once with the Tailscale IP and once with the MagicDNS name. If only the name fails, continue with DNS checks instead of changing routes or the DSM firewall.[2][9][10]

Interactive troubleshooter

Your answers stay in this browser tab. The tool does not connect to your NAS or send diagnostic results.

Guided check / step 1

Safe diagnostic guidance

Is the Synology NAS listed in Tailscale status?

Check from the client that is trying to reach the NAS. Peer visibility comes before service-level diagnosis.[2][5]

Read the complete diagnostic tree without using the controls
  1. Is the Synology NAS listed in Tailscale status?

    Check from the client that is trying to reach the NAS. Peer visibility comes before service-level diagnosis.[2][5]

    • Yes, the NAS is listed → Does tailscale ping to the NAS Tailscale IP succeed?
    • No, it is missing → Resolve peer membership or policy first
    • I have not checked → Check the expected tailnet and peer
  2. Check the expected tailnet and peer

    Run tailscale status and compare the NAS with the Machines page. Confirm the expected tailnet and authentication state.[2][5]

  3. Resolve peer membership or policy first

    A missing peer is not yet a DSM service-port problem. Verify authentication, the expected tailnet, and whether policy permits the peer to appear.[1][2][5]

  4. What did tailscale status show?

    Use the result from the same client. A listed NAS proceeds to the Tailscale IP path check; a missing NAS stays with peer membership, authentication, and tailnet access policy diagnosis.[2][5]

    • Yes, the NAS is listed → Does tailscale ping to the NAS Tailscale IP succeed?
    • No, the NAS is missing → Resolve peer membership or policy first
  5. Does tailscale ping to the NAS Tailscale IP succeed?

    Use the Tailscale IP for this discriminator. A path result is separate from application service reachability.[2][4]

    • Yes → Does the same service work by IP but fail by MagicDNS name?
    • No → Stay in the Tailscale path and control-plane branch
    • I have not tested it → Run the Tailscale path check
  6. Run the Tailscale path check

    Run tailscale ping with the NAS Tailscale IP. Record whether it succeeds and whether the path is direct or relayed.[2][4]

  7. Stay in the Tailscale path and control-plane branch

    Check client version, authentication, incoming-connection preference, device firewalls, and the tailnet access policy before changing a Synology service.[5][8][6]

  8. What did tailscale ping show?

    Use the result for the NAS Tailscale IP. A successful path check continues to hostname and service-port diagnosis; a failed check stays with peer, policy, incoming-connection, or firewall diagnosis.[5][8][4]

    • Yes, it succeeds → Does the same service work by IP but fail by MagicDNS name?
    • No, it fails → Stay in the Tailscale path and control-plane branch
  9. Does the same service work by IP but fail by MagicDNS name?

    Compare the same protocol and port so that hostname resolution is the only changed variable.[2][9][10]

    • Yes, only the name fails → This is a name-resolution branch
    • No, both fail → Can you reach the exact configured service port?
    • I am not sure → What did the IP and MagicDNS comparison show?
  10. What did the IP and MagicDNS comparison show?

    Test the same protocol, service, and port first by Tailscale IP and then by MagicDNS name. Keep the other variables unchanged, then choose the matching result.[2][9][8][10]

    • IP works, MagicDNS name fails → This is a name-resolution branch
    • Both fail → Can you reach the exact configured service port?
  11. This is a name-resolution branch

    Keep the working IP path unchanged. Inspect the client's Tailscale DNS preference and local, upstream, and Tailscale DNS settings.[8][10]

  12. Can you reach the exact configured service port?

    Confirm the DSM or package port locally before testing it; do not assume every Synology service uses 5001.[12][13][14][2]

    • Yes, the port responds → The tailnet path and TCP port are available
    • No, the port is blocked or closed → Inspect the service, policy, and DSM firewall
    • I do not know the port → After identifying the port, what did the exact-port test show?
  13. After identifying the port, what did the exact-port test show?

    First identify the configured port for the DSM or package service. DSM management ports can be changed, and package services use different ports. Then run tailscale nc with the NAS Tailscale IP and that exact port, and choose the observed result.[2][3][12][13][14]

    • Yes, the port responds → The tailnet path and TCP port are available
    • No, the port is blocked or closed → Inspect the service, policy, and DSM firewall
  14. The tailnet path and TCP port are available

    Continue with the specific Synology application's own login, URL, protocol, or certificate troubleshooting. Do not change Tailscale routing based on this result alone.[2][14]

  15. Inspect the service, policy, and DSM firewall

    Verify that the service is listening on the configured port and Preview the tailnet rule for that port. On DSM 7, also inspect the first matching firewall rule; this page does not assume the same firewall interface on DSM 6.[7][5][11][12][13]

Detailed diagnosis

Read-only

1. Establish peer visibility

The status command lists only peers the current device can access. If the NAS is absent, verify the expected tailnet, authentication state, and tailnet access policy before investigating DSM ports.[2][5]

tailscale status
Safe network check

2. Separate the tunnel from the service

Tailscale ping tests Tailscale connectivity. Test the intended DSM or package service separately because a path response does not establish that the operating-system service is listening or permitted.[4][2][14]

tailscale ping <nas-tailscale-ip>
tailscale nc <nas-tailscale-ip> <port>
Read-only

3. Check the tailnet access policy

A customized tailnet access policy can deny the connection even when both devices are online. Verify that the client identity can reach the NAS and the required port; administrators can use Preview rules.[6][7][5]

Read-only

4. Check incoming-connection preference

A device with incoming connections blocked remains visible and can send traffic, but it does not accept Tailscale connections, including pings.[8]

Read-only

5. Inspect the DSM firewall

In DSM 7, firewall rules can match specific ports and source IPs, and evaluation stops at the first matching rule. Inspect the active profile, interface, exact port, source, and earlier rules. This page does not assume that the DSM 6 firewall interface is identical.[11]

Read-only

6. Verify the configured Synology service port

Synology documents default DSM management ports of HTTP 5000 and HTTPS 5001 for both the DSM 6 settings page and DSM 7 Login Portal, and both versions allow those ports to be changed. Other Synology services may use different ports.[12][13][14]

Read-only

7. Keep the DSM 7 TUN branch conditional

On DSM 7, Tailscale allows inbound connections to the Synology device by default, while outbound Tailscale access from other NAS applications is not enabled by default.[1]

Supported failure modes

These are possibilities until the associated check distinguishes them.

The tailnet access policy does not allow this identity and port

A new tailnet starts with a default policy that allows communication between all devices. When custom grants or legacy ACL rules are used, connections that the effective tailnet access policy does not permit are denied. Both forms are directional, and Tailscale recommends grants for new configurations.[6]

How to check: Use Preview rules for the client identity, NAS destination, and required service port.[7][5]

Incoming Tailscale connections are blocked on the destination

The incoming-connections preference can leave a device visible while refusing inbound Tailscale connections.[8]

How to check: Inspect the destination client preference or applicable managed policy before changing it.[8]

The IP path works but name resolution does not

MagicDNS registers device names, while client, local, upstream, and Tailscale DNS configuration can still produce a name-only failure.[9][10]

How to check: Compare the same service by Tailscale IP and MagicDNS name, then inspect whether the client uses Tailscale DNS settings.[2][8][10]

The target service or port is different or blocked

DSM 6 and DSM 7 management ports are configurable, Synology packages do not all use the same ports, and a DSM 7 firewall rule can allow or deny the exact port by source and priority.[12][13][14][11]

How to check: Confirm the configured service port locally, then compare a Tailscale path result with a connection to that exact port.[2][12][13][14]

A package reinstall left the NAS disconnected from the tailnet

Tailscale documents a Synology recovery flow after uninstalling and reinstalling the package when the NAS no longer connects to the tailnet.[1]

How to check: Check the Machines page and status output before using the documented re-authentication flow.[1][2]

A Synology application needs outbound tailnet access on DSM 7

DSM 7 package restrictions prevent other applications on the NAS from using outbound Tailscale connectivity by default because the package cannot create a TUN device.[1]

How to check: Use this cause only when an application on the NAS is initiating the connection; do not infer it from an inbound DSM access failure.[1]

Fixes after confirmation

Read the risk, recovery access, and rollback before applying a change. A successful diagnostic branch is not authorization to make a broad firewall or policy change.
Safe network check

Use the verified service address and port

After confirming the local service configuration, connect with the matching scheme, Tailscale IP or working MagicDNS name, and exact port. Synology documents 5000 and 5001 as the default DSM 6 and DSM 7 management ports, but those values are configurable and package services differ.[12][13][14][9]

Potentially disruptive

Restore Tailscale DNS use only for a confirmed name-only failure

If the service works by Tailscale IP and the client was configured not to use Tailscale DNS, re-enable that preference and retest the same hostname.[8][10]

tailscale set --accept-dns=true

Before changing anything

Risk
Changing DNS acceptance changes which resolver settings the client uses and can affect other names, not just the NAS.[8][10]
Safer check
First prove that the Tailscale IP works while the MagicDNS name fails, and inspect the current client DNS preference.[2][8][10]
Expected result
The same MagicDNS name should resolve and the previously working IP-based service test should also work by name. If it does not, restore the prior preference and continue checking local, upstream, and tailnet DNS settings.[8][10]
Backup / recovery access
Record the current Use Tailscale DNS setting and retain a working IP-based access path before changing it.[8]
Rollback
If the change causes unwanted DNS behavior, restore the previous disabled state with tailscale set --accept-dns=false.[8]
Potentially disruptive

Make the narrowest confirmed tailnet access-policy correction

If the Preview rules view confirms a denial, update only the identity, NAS destination, protocol, and service port that require access in the tailnet access policy. Do not replace a restrictive policy with a blanket allow rule.[6][7][5]

Before changing anything

Risk
A tailnet access-policy edit can either lock users out or grant broader access than intended.[6]
Safer check
Use Preview rules to confirm the current result for the exact source, destination, and port before editing.[7][5]
Expected result
Preview rules should show the intended identity as allowed to the NAS and service port, and the same connection test should succeed after the policy is saved.[7][5]
Backup / recovery access
Preserve the current policy text and its working access tests so the prior state can be restored.[6]
Rollback
Restore the saved policy if the intended connection still fails or unrelated access changes.[6]
Potentially disruptive

Add a scoped DSM firewall rule only after confirming the block

On DSM 7, if the active firewall profile blocks the verified service port, create a rule limited to that port and the required source. Separately, when DSM 7 TUN has been enabled for outbound NAS applications, Tailscale instructs users with the Synology firewall enabled to allow 100.64.0.0/10; do not apply that subnet exception as a generic inbound fix without that prerequisite.[11][1]

Before changing anything

Risk
A remote firewall change can remove your only management path or expose more services than intended.[11][1]
Safer check
For DSM 7, keep local or console access, identify the active interface and profile, and verify the exact service port and first matching rule before editing. This page does not provide an unverified DSM 6 menu path.[11][12][13][14]
Expected result
The same exact-port connection test should succeed from the intended source after the DSM 7 rule is applied, without granting access to additional ports or sources.[11][2]
Backup / recovery access
Record the active DSM 7 firewall profile, default action, and rule order before adding a rule.[11]
Rollback
If access worsens, use local recovery access to remove the new rule and restore the recorded rule order and default action.[11]

Warnings and boundaries

Do not disable the DSM 7 firewall or replace the tailnet access policy with a broad allow-all rule as a generic test. Inspect the exact source, destination, port, interface, and rule order first; verify DSM 6 firewall controls separately before changing them.[11][6][5]
Do not run the DSM 7 configure-host procedure for an ordinary inbound DSM failure. It is documented for outbound connectivity from other applications on the NAS and restarts the Tailscale package.[1]
A failed ordinary ping is not decisive for a resource reached through a subnet shared by Synology: hybrid networking can carry UDP and TCP without necessarily supporting ping.[1]

Sources

Links were reviewed on 2026-09-02. Reachability and automated validation do not replace editorial verification of each claim.

  1. Access Synology NAS from anywhere
    Tailscale · Tier A · accessed 2026-09-02
  2. Tailscale CLI
    Tailscale · Tier A · accessed 2026-09-02
  3. cmd/tailscale/cli/nc.go
    Tailscale · Tier B · accessed 2026-09-02
  4. Tailscale ping message types
    Tailscale · Tier A · accessed 2026-09-02
  5. Can't connect to other tailnet devices
    Tailscale · Tier A · accessed 2026-09-02
  6. Manage permissions using ACLs
    Tailscale · Tier A · accessed 2026-09-02
  7. Troubleshooting grants
    Tailscale · Tier A · accessed 2026-09-02
  8. Manage client preferences
    Tailscale · Tier A · accessed 2026-09-02
  9. MagicDNS
    Tailscale · Tier A · accessed 2026-09-02
  10. Can't resolve domain names
    Tailscale · Tier A · accessed 2026-09-02
  11. Firewall | DSM
    Synology · Tier A · accessed 2026-09-02
  12. DSM Settings | DSM 6
    Synology · Tier A · accessed 2026-09-02
  13. DSM Login Portal | DSM 7
    Synology · Tier A · accessed 2026-09-02
  14. What network ports are used by services on my Synology system?
    Synology · Tier A · accessed 2026-09-02