The NAS That Needed a Fence

Date: August 13, 2023 Issue: Accessing Synology NAS from work Approaches: VPN (safe) vs WAN exposure (risky) Result: VPN with firewall restrictions

The Problem

I had files on my Synology NAS at home that I needed to access from work. Scripts, documentation, the occasional ISO that lived on the array.

The NAS was at 192.168.1.10. Work was… not on my home network.

Simple question: how do I get to those files?

Option 1: VPN (The Right Way)

I already had OpenVPN running on pfSense. The VPN was for pentesting lab access, but nothing stopped me from using it for NAS access too.

The setup was straightforward:

Create a share on the Synology (DSM → Control Panel → Shared Folder)
Export an OpenVPN client config from pfSense
Connect from work, access the share like it’s local

But I wanted to be surgical about it. VPN clients shouldn’t have access to my entire home network. Just the NAS.

Restricting VPN Access

In pfSense (Firewall → Rules → OpenVPN):

PASS: VPN subnet → 192.168.1.10 (TCP 445)
BLOCK: VPN subnet → Any

This meant VPN clients could only talk to the NAS on the SMB port. Nothing else. Can’t SSH to my workstation. Can’t reach the IoT garbage. Can’t pivot anywhere.

Also adjusted the OpenVPN server config:

IPv4 Local network(s): 192.168.1.10/32

Don’t push routes for the whole LAN. Just push a route for the NAS.

Option 2: WAN Exposure (The Risky Way)

I also asked: what if I skip the VPN entirely and just expose the NAS to the internet?

This is where the conversation got educational.

The “Just Forward Port 5001” Approach

Port 5001 is DSM’s HTTPS interface. Forward that, access the web UI from anywhere.

Problems:

Anyone can hit the login page
Brute-force attacks are trivial
Zero-days in DSM = instant compromise

The Security Mitigations

If I had to expose it (I didn’t), here’s what the hardening would look like:

Random external port. Don’t use 5001 externally. Pick something obscure (like 7293). Security through obscurity isn’t security, but it stops the casual scanner.
HTTPS only. Get a real certificate via Let’s Encrypt. No HTTP. Ever.
Dedicated user. Never expose admin. Create a read-only user that can only see the specific share.
Synology firewall. Built into DSM. Restrict by geography or IP range.
Auto-block. 5 failed logins = IP blocked for 24 hours. Brute-force becomes impractical.
2FA. Obviously.

Why I Didn’t Do This

Because VPN exists.

All that hardening? It’s work. It’s maintenance. It’s attack surface. The VPN approach gives me encrypted traffic, no public exposure, and identical functionality.

There’s no scenario where “expose SMB to the internet” is the right choice.

The Actual Config

Here’s what I ended up with:

pfSense OpenVPN Server:

Local network(s): 192.168.1.10/32
Tunnel network: 10.8.0.0/24

pfSense Firewall (OpenVPN tab):

Rule 1: PASS - Source: 10.8.0.0/24, Dest: 192.168.1.10, Port: 445/TCP
Rule 2: BLOCK - Source: 10.8.0.0/24, Dest: Any

Work laptop:

# Connect VPN
sudo openvpn --config home.ovpn

# Access share
# \\192.168.1.10\WorkFiles

That’s it. Files accessible. Everything else locked down.

What I Learned

VPN is always the answer. For remote access to home resources, there’s no scenario where exposing services directly beats encrypted tunneling.

Firewall rules are about restriction, not permission. The default should be “block everything.” Then allow what’s needed.

Users are scoped to resources. The work VPN connection uses credentials that only allow SMB access. Even if someone stole those creds, they couldn’t do anything but list files.

Security is layers. VPN + restricted routing + firewall rules + limited user permissions. Each layer assumes the previous one failed.

Later Evolution

This setup lasted about six months. Then Tailscale happened.

One binary. Mesh networking. Automatic encryption. No port forwarding. No firewall rules. Just… it works.

But in August 2023, I didn’t know about Tailscale. OpenVPN and pfSense firewall rules were the tools I had. And they worked.

The question isn’t “can I expose this to the internet?” It’s “should I?”