I'm having trouble configuring CIFS on my FreeNAS 9.3 system. Can anyone see what might be
causing the following behaviour in my environment?
Here's where I start from:
--------------------------
The ip address of the FreeNAS system is 192.168.1.10/24, default route is 192.168.1.1 (points to a consumer grade dsl router). All of the PC's inside the house go through this router to the ISP's internet connection. I configure CIFS shares on FreeNAS, start the service, everything behaves exactly as I want. Everyone who is on the 192.168.1.0/24 subnet and is in the same workgroup as specified in the CIFS service and share definitions can discover the host, open the folders & read/write to them. Success!
Now the problem begins:
-----------------------
I configure a second network interface on FreeNAS from the console, address 192.168.4.10/24 (different subnet). It is connected to another DSL router whose address is 192.168.4.1. At the FreeNAS console, I change the default route to 192.168.4.1 since that is where I want locally-unknown traffic to route to. At this point, all is well. I can ssh to the FreeNAS systems, ping both routers and everyone on 192.168.1.0/24 continues to merrily access the FreeNAS CIFS shares or browse the web.
Next, I decide to configure the CIFS service to only listen to the 192.168.1.10 interface. It's apparently easy, there is a configuration box in the CIFS service configuration screen which indicates which interfaces the CIFS service will listen on. The information pop-up says that the default is both interfaces. To listen to just the 192.168.1.10 interface, I place a check in the box next to it and apply the changes. I'm asked to wait while the changes are applied.
At this point, a problem occurs in my environment. Specifically, my windows SMB clients can still see the NETBIOS name of the CIFS share but they can no longer open it to view the files within: "[hostname] is no longer acessible". Same with my linux systems that used to be able to browse the folders. If I look on the FreeNAS system, I can see where the file /etc/local/smb4.conf has had 2 lines added that read "bind interfaces only = yes" and "interfaces = 127.0.0.1 192.168.1.10", which is what I expect from my reading of the SMB documentation. Everyone in the 192.168.1.0/24 network is still surfing the web successfully even though they can no longer access any of the CIFS shares.
Since all the CIFS service accessors have addresses in the 192.168.1.0/24 subnet and all of them use 192.168.1.1 as their gateway, I didn't think the FreesNAS environment would need a route added just for this 192.168.1.0/24 network in order for the CIFS service to work as I expected. I decided to add one anyway, just to see what would happen. So I went to the FreeNAS GUI, added a static route "192.168.1.0/24" and set its next hop to 192.168.1.1. Rebooted FreeNAS, no change in behaviour when accessing CIFS shares from 192.168.1.1: the clients can still see the NETBIOS name of the FreeNAS CIFS host but cannot open it's folder.
After a lot of troubleshooting, I believe the problem comes down to the interaction between the default route on FreeNAS server and the SMB daemon. If I remove the static route entry for 192.168.1.0/24 and change the default route at the FreeNAS console back to 192.168.1.1 then reboot, all of my SMB client's problems dissappear and they behave as they did before.
So does anyone have an idea as to:
1. Why the SMB daemon cannot send traffic via 192.168.1.0/24 to clients in the same subnet without
a route being added?
2. Why doesn't the addition of a static route statement for 192.168.1.0/24 traffic to go to 192.168.1.1
NOT work to get SMB traffic passing over 192.168.1.10?
3. Why does having the FreeNAS default route set to 192.168.1.1 cause the SMB daemon to send traffic over the 192.168.1.10 interface?
4. What do I need to do to get the default route out to 192.168.4.1 AND have the SMB daemon listen
only on 192.168.1.10 successfully?
causing the following behaviour in my environment?
Here's where I start from:
--------------------------
The ip address of the FreeNAS system is 192.168.1.10/24, default route is 192.168.1.1 (points to a consumer grade dsl router). All of the PC's inside the house go through this router to the ISP's internet connection. I configure CIFS shares on FreeNAS, start the service, everything behaves exactly as I want. Everyone who is on the 192.168.1.0/24 subnet and is in the same workgroup as specified in the CIFS service and share definitions can discover the host, open the folders & read/write to them. Success!
Now the problem begins:
-----------------------
I configure a second network interface on FreeNAS from the console, address 192.168.4.10/24 (different subnet). It is connected to another DSL router whose address is 192.168.4.1. At the FreeNAS console, I change the default route to 192.168.4.1 since that is where I want locally-unknown traffic to route to. At this point, all is well. I can ssh to the FreeNAS systems, ping both routers and everyone on 192.168.1.0/24 continues to merrily access the FreeNAS CIFS shares or browse the web.
Next, I decide to configure the CIFS service to only listen to the 192.168.1.10 interface. It's apparently easy, there is a configuration box in the CIFS service configuration screen which indicates which interfaces the CIFS service will listen on. The information pop-up says that the default is both interfaces. To listen to just the 192.168.1.10 interface, I place a check in the box next to it and apply the changes. I'm asked to wait while the changes are applied.
At this point, a problem occurs in my environment. Specifically, my windows SMB clients can still see the NETBIOS name of the CIFS share but they can no longer open it to view the files within: "[hostname] is no longer acessible". Same with my linux systems that used to be able to browse the folders. If I look on the FreeNAS system, I can see where the file /etc/local/smb4.conf has had 2 lines added that read "bind interfaces only = yes" and "interfaces = 127.0.0.1 192.168.1.10", which is what I expect from my reading of the SMB documentation. Everyone in the 192.168.1.0/24 network is still surfing the web successfully even though they can no longer access any of the CIFS shares.
Since all the CIFS service accessors have addresses in the 192.168.1.0/24 subnet and all of them use 192.168.1.1 as their gateway, I didn't think the FreesNAS environment would need a route added just for this 192.168.1.0/24 network in order for the CIFS service to work as I expected. I decided to add one anyway, just to see what would happen. So I went to the FreeNAS GUI, added a static route "192.168.1.0/24" and set its next hop to 192.168.1.1. Rebooted FreeNAS, no change in behaviour when accessing CIFS shares from 192.168.1.1: the clients can still see the NETBIOS name of the FreeNAS CIFS host but cannot open it's folder.
After a lot of troubleshooting, I believe the problem comes down to the interaction between the default route on FreeNAS server and the SMB daemon. If I remove the static route entry for 192.168.1.0/24 and change the default route at the FreeNAS console back to 192.168.1.1 then reboot, all of my SMB client's problems dissappear and they behave as they did before.
So does anyone have an idea as to:
1. Why the SMB daemon cannot send traffic via 192.168.1.0/24 to clients in the same subnet without
a route being added?
2. Why doesn't the addition of a static route statement for 192.168.1.0/24 traffic to go to 192.168.1.1
NOT work to get SMB traffic passing over 192.168.1.10?
3. Why does having the FreeNAS default route set to 192.168.1.1 cause the SMB daemon to send traffic over the 192.168.1.10 interface?
4. What do I need to do to get the default route out to 192.168.4.1 AND have the SMB daemon listen
only on 192.168.1.10 successfully?
