Synology Tailscale / Troubleshooting
Synology Tailscale Subnet Router: LAN Device Unreachable
NAS access works, but a LAN service behind it does not. Separate subnet advertisement, CIDR, approval, access policy, client routing and target-side evidence.
Treat the route and permission to use it as separate evidence. A route can exist while access is denied; an allow rule cannot create a missing route.[2]
Applicability
- Products
- Synology DSM · Tailscale
- Scope
- For a remote Tailscale client reaching a known TCP/UDP service on a non-Tailscale LAN target through a reachable Synology NAS. Record DSM and package versions. Excludes NAS-service failure, site-to-site setups, exit nodes and DNS-only problems. Synology can advertise routes but currently cannot accept other subnet routes.[1]
- Last verified
Symptoms
Quick diagnosis
Gather the relevant observations before choosing a branch. Unknown evidence is not proof of a failed component.
Identify the exact destination
Record the target IP, intended subnet, protocol and configured service port. In the admin console, inspect the NAS's advertised ranges without changing them.[4]
Try the intended service, not a ping gate
Use a normal, non-destructive operation in the intended application. Synology hybrid networking can carry TCP/UDP without successful ordinary ping.[1]
Interactive troubleshooter
Your answers stay in this browser tab. The tool does not connect to your systems or send diagnostic results.
Guided check / step 1
Safe diagnostic guidanceCan you access the Synology NAS itself through Tailscale?
Confirm real NAS access before investigating the LAN target.[1]
Read the complete diagnostic tree without using the controls
- Can you access the Synology NAS itself through Tailscale?
Confirm real NAS access before investigating the LAN target.[1]
- Yes, NAS access works → Is the intended subnet advertised by this NAS?
- No, or not established → Use the existing NAS-reachability diagnosis
- Is the intended subnet advertised by this NAS?
Inspect the NAS route advertisement in the admin console.[4]
- Yes, an intended subnet is advertised → Does that advertised CIDR contain the LAN target?
- No advertisement found → Have the owner review the missing advertisement
- I cannot establish the advertisement → Gather the missing observation before a change
- Does that advertised CIDR contain the LAN target?
Compare the target address with the advertised range.[4]
- Yes, the target is inside it → Is that route approved or enabled?
- No, the target is outside it → Resolve the target/CIDR mismatch first
- I have not established the range → Gather the missing observation before a change
- Is that route approved or enabled?
Approval may be manual or supplied by auto-approval.[3]
- Yes, approval is confirmed → Does the effective policy allow this subnet destination?
- No, it is not approved → Request review of the unapproved route
- Approval is unknown → Gather the missing observation before a change
- Does the effective policy allow this subnet destination?
Verify the requesting identity and intended protocol/port.[2]
- Yes, this connection is permitted → Is the remote client accepting and using the route?
- No, the policy denies it → Request review of the denied destination
- Permission is not established → Gather the missing observation before a change
- Is the remote client accepting and using the route?
Inspect its settings and actual destination route.[3]
- Yes, the expected route is in use → Is there an overlapping local range or destination ambiguity?
- No, acceptance or route use is missing → Review this client's route configuration
- Client route behavior is unknown → Gather the missing observation before a change
- Is there an overlapping local range or destination ambiguity?
Compare the client's current LAN range with the NAS-advertised range.[5]
- Yes, overlapping ranges need investigation → Investigate possible routing ambiguity
- No conflicting range is evident → Does the intended TCP/UDP service respond?
- I cannot establish the destination path → Gather the missing observation before a change
- Does the intended TCP/UDP service respond?
Use the intended application operation; ordinary ping is not a required gate.[1]
- Yes, the service works → The intended service works; no broken-route conclusion
- Service works, but ordinary ping fails → The intended service works; no broken-route conclusion
- No, the service still fails → Does the same service work from the relevant NAS/LAN side?
- The intended service has not been tested → Gather the missing observation before a change
- Does the same service work from the relevant NAS/LAN side?
Prefer a supported test from the NAS; another LAN host does not prove the NAS's path.[2]
- Yes, NAS-side service access works → Escalate the remaining remote-versus-local difference
- No, LAN-local service access also fails → Investigate the target/LAN/service boundary
- NAS-side access is unknown or untestable → Gather the missing observation before a change
- Use the existing NAS-reachability diagnosis
Stop this routed-LAN workflow. Follow the golden-page link in Next actions for NAS endpoint diagnosis.[1]
- Have the owner review the missing advertisement
Do not invent a subnet or advertise a broader range to continue.[4]
- Resolve the target/CIDR mismatch first
Verify addressing with the LAN owner before requesting a route change.[4]
- Request review of the unapproved route
Approval is a separate administrative decision, not proof of service access.[3]
- Request review of the denied destination
Preserve the denied identity and destination details; do not broaden access to everyone.[3]
- Review this client's route configuration
Use the client's supported platform guidance. Do not enable route acceptance on Synology as a substitute.[3][1]
- Investigate possible routing ambiguity
Have a network owner inspect the actual selected path. This result does not assert which route wins.[5]
- The intended service works; no broken-route conclusion
A failed ordinary ping alone does not justify changing this working service path.[1]
- Investigate the target/LAN/service boundary
Use target-specific evidence before attributing the failure to firewall or binding. No firewall-disable test.[2]
- Escalate the remaining remote-versus-local difference
Provide the stage-by-stage observations to the network owner; the comparison narrows investigation, not a deterministic cause.[2]
- Gather the missing observation before a change
Record the unresolved stage and ask its owner to inspect it. Unknown is not a failed prerequisite.[3]
Detailed diagnosis
1. Check advertisement, CIDR and approval separately
Inspect the advertised subnet and confirm that its CIDR contains the target. Check approval independently; an existing auto-approval rule may already satisfy it.[4][3]
2. Inspect destination permission
Ask the tailnet administrator to verify the actual source identity, subnet destination and intended protocol/port. NAS access is not proof of LAN-target permission.[2]
3. Inspect the requesting client's route behavior
Linux clients require route acceptance to be enabled; Windows, macOS and mobile clients listed in the subnet-router guide accept by default. Defaults are not proof of current settings. Inspect the effective destination path on the requesting client, not route acceptance on Synology.[3]
4. Compare local and remote address ranges
If both LANs use the same CIDR, investigate possible destination ambiguity. Actual behavior depends on platform and routing state; neither the local nor advertised route universally wins.[5]
5. Compare the relevant LAN-side service
The Route Injection reference recommends checking destination reachability from the subnet router. Use the same intended service from the NAS where supported. Another LAN device is only partial evidence: its path may differ. If local access fails too, inspect the target's service state, listening address and firewall using its own documentation; none is a confirmed cause yet.[2]
Supported scenarios
These observations narrow the investigation; they do not establish a unique cause.
The required subnet is not available to the client
Advertisement, approval and client acceptance are independent prerequisites.[2]
How to check: Identify which stage is missing before planning any correction.[4]
The effective policy does not permit the destination
Route installation does not grant access.[2]
How to check: Have the administrator inspect permission for this exact connection.[3]
Overlapping ranges need route-level investigation
An overlapping local network can require platform-specific analysis.[5]
How to check: Compare actual routes and intended host identity, not just address spelling.[5]
Next actions and procedure boundaries
Request a scoped control-plane correction
If a stage is missing, provide its observed state to the tailnet owner. Request review of only the required subnet and destination permission. This is a planning handoff, not an instruction to change routes or grants.[3]
Keep unresolved target failures with the relevant owner
If LAN-local service access also fails, stop treating Tailscale as the established cause. If local access works but remote access fails after the preceding checks, provide the comparison to the network owner. HomeLabFix's isolation recommendation does not identify a specific firewall rule or service-binding defect.[2]
Escalate overlap or unverified DSM forwarding
Request a platform-specific plan for routing ambiguity or suspected forwarding limitations. Generic Linux setup guidance is not a verified DSM procedure. Route rewriting, 4via6 and subnet redesign are outside this diagnosis.[5][4]
Warnings and boundaries
Sources
Links were reviewed on 2026-09-05. Reachability and automated validation do not replace editorial verification of each claim.
- Access Synology NAS from anywhere
Tailscale · Tier A · accessed 2026-09-02 - Route injection
Tailscale · Tier A · accessed 2026-09-05 - Subnet routers
Tailscale · Tier A · accessed 2026-09-05 - Configure a subnet router
Tailscale · Tier A · accessed 2026-09-05 - LAN traffic prioritization with overlapping subnet routes
Tailscale · Tier A · accessed 2026-09-05