How to create a Cloudflare Tunnel for your NAS
Remote access to a Synology or QNAP NAS is convenient, but ordinary router port forwarding exposes the device directly to the internet. A Cloudflare Tunnel reverses that model: cloudflared, running on the NAS, opens an outbound connection to Cloudflare, and traffic reaches the NAS through Cloudflare’s authenticated edge.
This matters across Australia, where an NBN service may use FTTP, FTTN, fixed wireless or a CGNAT connection, and a changing home IP can complicate access. It also suits a NAS in a Sydney, Melbourne or Brisbane home without asking the router to accept incoming connections. The setup needs a domain and Docker support on the NAS.
Use this guide to publish a specific web application, not the entire NAS administration surface. Work from a recent DSM or QTS backup, create a separate low-privilege account, and first confirm that the application works over the local network. The public service URL should later be protected with strong identity checks and encrypted transport.
How the tunnel moves traffic
The tunnel has three useful parts: a cloudflared connector on the NAS, a route in Cloudflare’s network, and a public hostname such as files.example.com.au. When someone opens that hostname, Cloudflare authenticates the request and forwards it through the existing outbound tunnel.
The connector initiates traffic to Cloudflare over port 7844, using UDP where available and falling back to TCP. Your router therefore needs no inbound 80 or 443 rule for the NAS. Outbound DNS and access to the Docker registry must still work, and a corporate or school firewall may require an exception.
Cloudflare handles public TLS and can absorb basic volumetric attacks before they reach the home connection. It does not replace application authentication: the NAS app must still validate users, use current firmware and reject weak passwords. The tunnel is a transport layer around your existing services.
Prepare the NAS and domain
On Synology, install or update Container Manager from Package Center; supported QNAP models provide Container Station. Give the NAS a DHCP reservation, verify its clock is automatic, and confirm the target app works at its LAN address. A NAS reboot should bring back both the app and its Docker service.
Use a private LAN address such as 192.168.1.20, not localhost, because localhost inside the connector refers to the container itself. If several apps will be shared, put the NAS’s reverse proxy in front of them and give each public hostname its own backend route. Keep the DSM or QTS administration interface for local use.
The domain’s authoritative nameservers must point to Cloudflare before a tunnel hostname can be managed there. A .com.au domain bought through an Australian registrar can be used in the same way as any other zone. Remove an old A or AAAA record for the chosen hostname, because Cloudflare cannot create its tunnel route while another record controls the same name.
Create the tunnel in Cloudflare
Sign in to the Cloudflare Zero Trust dashboard, open Networks and then Tunnels, and create a Cloudflared tunnel with a clear name such as home-nas. Choose Docker as the environment. The dashboard generates a token and an installation command containing it; treat both as administrative secrets and never publish them in a script, screenshot or shared document.
Add a public hostname with a subdomain such as files and your domain. Set the service type and URL to the NAS reverse proxy or application port. For example, an HTTPS reverse proxy might listen at https://192.168.1.20:8443; match its virtual host to the public hostname so the correct app is selected.
Cloudflare normally creates the required proxied DNS record when the hostname is saved. Check that the files record is orange-clouded and that no conflicting address remains. Keep DNS management separate from application login: one controls where the hostname resolves, while Access controls who may use it.
Run cloudflared on the NAS
In Container Manager or Container Station, create a container from cloudflare/cloudflared and paste the generated tunnel command as its startup command. A Docker Compose project can use the following form, replacing the placeholder with the token shown in the dashboard:
services:
cloudflared:
image: cloudflare/cloudflared:latest
container_name: cloudflared
restart: unless-stopped
command: tunnel --no-autoupdate run --token YOUR_TUNNEL_TOKEN
Set the restart policy to restart unless stopped, and do not publish container ports. The connector makes an outbound connection, so inbound port mapping is unnecessary. If your interface accepts a Docker command directly, the equivalent is docker run -d --name cloudflared --restart unless-stopped cloudflare/cloudflared:latest tunnel --no-autoupdate run --token YOUR_TUNNEL_TOKEN.
Check the container logs for a registration message and several healthy connections. Repeated connection or timeout errors usually point to blocked outbound port 7844, DNS trouble or a system clock issue. Once it is stable, pin the image to a tested current release rather than leaving every restart dependent on the moving latest tag, and establish a schedule for controlled updates.
Add identity and application security
Create a Cloudflare Access application for the exact public hostname under Access, Applications, Add an application, then Self-hosted. Start with an Allow policy restricted to named email addresses or a managed group, and require multifactor authentication through the identity provider already used by your household or business.
Choose a sensible session duration and test a denied account before relying on the service. Service tokens are useful for automated API clients, but they should not be embedded in browser-based photo galleries or other apps intended for human logins. If the NAS application has its own accounts, keep both layers: Access controls the edge, while the application controls specific files and permissions.
Terminate TLS at the NAS’s reverse proxy when possible, using a certificate the connector can verify. If an internal certificate is self-signed, configure a trusted certificate authority and the correct origin server name; do not use noTLSVerify merely to silence the first error. The hostname shown by Cloudflare must match the certificate, while the service URL still points to the private NAS address.
Verify access away from the home network
Use an Australian mobile 4G or 5G connection, or another network outside the house, to open the hostname. A redirect to the Cloudflare Access sign-in screen is expected before the NAS app appears. Confirm that sign-in succeeds, then test the app’s important paths: file browsing, uploads, downloads, web sockets and any mobile access the service requires.
Run curl -I https://files.example.com.au from the outside network if needed. An Access redirect or an HTTP 200 response is a useful signal; a DNS, 521, 522 or 524 error points respectively toward naming, connection or timeout issues. Keep local users on the private address or split-horizon DNS, because sending local traffic out to the Cloudflare edge and back can add delay.
Cloudflare’s network includes Australian infrastructure, with Sydney among its points of presence, which can shorten the path for many Australian users, but the route from Melbourne or Brisbane still depends on the NBN line and ISP. Check actual latency and throughput rather than relying on the nearest city label. The standard Free plan also has a 100 MB per-request upload limit, making it unsuitable for pushing large backup archives through the hostname.
Keep the tunnel secure and maintainable
Review Access policies, active sessions and Cloudflare logs regularly. Remove users who no longer need access, rotate the tunnel token if it appears in an email or repository, and apply NAS, container and reverse-proxy updates promptly. Tunnel traffic is not a backup, so retain an independent copy of important data using a suitable 3-2-1 approach, including an offline copy if your risk profile warrants it.
For Australian businesses, the Privacy Act 1988 and Australian Privacy Principles may apply when personal information is accessed through the service. Review Cloudflare’s current data-location terms, subprocessors and your contractual basis; a global edge network should not be assumed to keep every record in Australia. The same review should cover what NAS logs, application logs and authentication providers can retain.
Do not repurpose an ordinary web tunnel to expose SMB, iSCSI or similar administrative protocols. Use a properly designed private VPN for those workloads, and assess high-volume media streaming against Cloudflare’s current service terms and plan limits. Monitor tunnel health after reboots, and keep one tested local access path so a policy or account change cannot lock you out of your own data.
Start with a controlled rollout. Choose one low-risk application, create its reverse-proxy route, add the tunnel, and test the complete sign-in flow before adding another hostname. This keeps the first deployment small enough to diagnose and avoids turning the NAS into an open collection of remote services.
Create the Cloudflare Tunnel, enforce an Access policy, and validate it over mobile data now. Your NAS can then be reached through its secure public hostname without opening a single inbound port on your home router.