How I Fixed SMB Access Issues to My Home NAS Behind a VLAN-Enabled Router

When I recently set up my home lab, I ran into a frustrating snag: I couldn’t connect to my NAS SMB share from my PC, even though basic network connectivity (ping) was working perfectly. Here’s how I diagnosed and fixed the problem — hopefully this helps you too.

The Scenario

• Server: NAS device running FreeBSD-based OS with multiple network interfaces on different VLANs.
• Router: VLAN-capable router running RouterOS managing multiple isolated subnets.
• Client: Windows workstation on a separate VLAN subnet.
• Problem: The client could ping the NAS IP address, but SMB connections to the network share kept failing with generic network errors.

Step 1: Confirm Basic Network Connectivity

I started by verifying the basics:

• Verified the client could ping the NAS IP address successfully.
• Checked the NAS interfaces to confirm they had IPs in their respective VLAN subnets.
• Confirmed routing between VLANs was operational.

This confirmed that Layer 3 routing and VLAN tagging were functioning.

Step 2: Review Router Firewall Rules

Next, I examined firewall rules on the router. Initially, attempts to insert new firewall rules failed due to CLI syntax differences.

I added explicit accept rules allowing traffic to flow between the client VLAN subnet and the NAS VLAN subnet on the router’s firewall, specifically permitting SMB-related traffic (TCP ports 445 and 139):

/ip firewall filter add chain=forward src-address=CLIENT_VLAN_SUBNET dst-address=NAS_VLAN_IP action=accept comment="Allow Client VLAN to NAS"
/ip firewall filter add chain=forward src-address=NAS_VLAN_IP dst-address=CLIENT_VLAN_SUBNET action=accept comment="Allow NAS to Client VLAN"

Then I moved these rules above any default drop rules to ensure traffic wasn’t blocked.

Step 3: Validate NAS Network Configuration

On the NAS itself:

• Verified all network interfaces were UP and configured with correct IP addresses in their VLANs.
• Checked routing tables to confirm no conflicting or missing routes.

Step 4: Check SMB Service Status & Configuration on NAS

I made sure the SMB service was running properly:

shellCopyEditservice samba_server status

I also reviewed the Samba configuration file:

• Verified it was binding to the correct interfaces.
• Confirmed share definitions and permissions.
• Ensured SMB protocol version was set to at least SMB2 to avoid legacy compatibility issues.
• Enabled NetBIOS name service daemon to assist in network discovery.

Step 5: Test SMB Access by IP Address

Using Windows, I connected to the SMB share directly via the NAS IP address rather than a hostname, to bypass potential DNS or NetBIOS issues:

perlCopyEditnet use \\NAS_IP_ADDRESS\ShareName

This succeeded, confirming that both routing/firewall and SMB service were now working correctly.

What Was the Root Cause?

The main blockers were:

• Firewall rules on the router: Missing or improperly ordered rules were blocking SMB traffic between VLANs.
• Command syntax issues on RouterOS CLI: Trying to insert firewall rules incorrectly delayed configuration.
• SMB daemon settings on the NAS: The NetBIOS name service daemon was disabled initially, affecting discovery and connectivity.

Lessons Learned

• Always confirm IP-level connectivity before troubleshooting application-layer services.
• Understand your router’s firewall CLI syntax — sometimes commands like add and move are safer than insert.
• Ensure service daemons are properly enabled and configured on your NAS.
• Use IP address access for SMB shares when DNS or name resolution might be a problem.
• Check logs and use diagnostic commands (testparm, service status) to verify configurations.

Final Thoughts

Network troubleshooting can be tricky, but breaking it down step-by-step helped me get my SMB shares accessible again behind a segmented VLAN network.

If you want more hands-on networking and NAS setup tips, stick around and subscribe to my blog!