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
andmove
are safer thaninsert
. - 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!
Leave a Reply