Share on different interface

Patrick_3000

Contributor
Joined
Apr 28, 2021
Messages
167
At home, I have all my own computers on one network (which I'll call the primary network), and all other devices, including my spouse's computers, television, thermostat, etc. on a separate network (which I'll call the secondary network). The networks are isolated through OPNsense (which runs as a VM on SCALE) and managed switches.

The SCALE web UI is on the primary network, and currently all shares in SCALE are shared only with me on the primary network.

What I would like to do is create a Windows (SMB) share that both my spouse and I can access, and I would like this share to be on the secondary network (which as noted is different from the primary network that the SCALE UI is on). I could do this either by provisioning a separate physical interface on the SCALE server, since I have multiple physical interfaces to spare, or alternatively I could do it by creating a bridge to use as a virtual interface to the OPNsense VM.

However, the problem is that in SCALE's Share tab, I don't see any option to specify the interface on which to share a dataset. All shares, as far as I can tell, are shared on the same interface as the SCALE UI. So, perhaps there is no way to specify a separate interface for a share, However, maybe I'm missing it.

So to summarize: does anyone know if there is a way to specify an interface on which to share a dataset that is separate from the interface that the SCALE web UI is on?
 
Last edited:

chuck32

Guru
Joined
Jan 14, 2023
Messages
623
The SCALE web UI is on the primary network, and currently all shares in SCALE are shared only with me on the primary network.
I guess it's more of an issue regarding your separation of networks.

I have 0.0.0.0 as web gui address in my settings and I use two NICs in two different subnets (one is a direct crossover to my main PC) and I'm able to access my SMB shares over both subnets and also the GUI. I would assume, if you haven't configured anything otherwise, that the SMB shares and GUI should be available via all network interfaces. It reads like you haven't setup the second interface yet. Try it, it should work (given your network separation allows for it).
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
So to summarize: does anyone know if there is a way to specify an interface on which to share a dataset that is separate from the interface that the SCALE web UI is on?
You need to look at the settings for the particular service (NFS, SMB, etc). There are two relevant knobs:
* bind IPs (list of IP addresses the service will bind to) -- global
* hosts allow / deny - per share
 

Heracles

Wizard
Joined
Feb 2, 2018
Messages
1,401
You will also have to look at routing. A client from primary network will go through the firewall to reach the share but when the server answers it will see that it has direct access to that network range. One way to fool this is to do NAT when reaching your share from the primary network.

It would be best to host your share on the same network adapter where your default route is. Here, that means to open from secondary network to primary interface and port for reaching only that share. That is exactly what a firewall is meant for : to open only the required services and block the rest.
 

Patrick_3000

Contributor
Joined
Apr 28, 2021
Messages
167
Thanks, everyone, for your responses. I don't see a simple way to do this from either the Shares tab or the SMB service configuration; so I've decided to use a different approach. I am creating a Linux VM on SCALE and assigning it an interface on the secondary network, and I will host the Samba share in the VM. I will use rsync over SSH to backup the VM's shared data to SCALE every hour.
 

chuck32

Guru
Joined
Jan 14, 2023
Messages
623
Thanks, everyone, for your responses. I don't see a simple way to do this from either the Shares tab or the SMB service configuration;
What do you mean you see no simple way?

Bind IPs is under the SMB service tab -> advanced settings
Host allow / deny under the Shares tab -> edit share -> advanced settings

Bind IPs explicitly stated if you don't enter anything, it will listen to all active interfaces.
Same for host allow / deny
If neither *Hosts Allow* or *Hosts Deny* contains an entry, then SMB share access is allowed for any host.

So basically what I said, in default configuration neither are filled, so it should be accessible from all interfaces.

If that doesn't work, the error seems to lie in your network setup.
 

Patrick_3000

Contributor
Joined
Apr 28, 2021
Messages
167
What do you mean you see no simple way?

Bind IPs is under the SMB service tab -> advanced settings
Host allow / deny under the Shares tab -> edit share -> advanced settings

Bind IPs explicitly stated if you don't enter anything, it will listen to all active interfaces.
Same for host allow / deny


So basically what I said, in default configuration neither are filled, so it should be accessible from all interfaces.

If that doesn't work, the error seems to lie in your network setup.
Yes, I see what you mean. That should work, even though as I've thought this through, I'm not sure it's the best approach for me because it would put the entire SCALE server on the secondary network. SCALE would be assigned an IP address on the secondary network and a different IP address on the primary network, and anyone on either network could access SMB shares (albeit subject to user/password protection).

I'm glad this is documented for those who want to do this, but for me, as noted, I'm not thrilled about it because it exposes all my SMB shares on SCALE to the secondary network, not just the specific dataset I'm interested in sharing on the secondary network. And as I think about it, it would almost have to be that way because the SCALE server would have an IP address on the secondary network.

I'm not at all worried about anyone in my home on the secondary network having access to all my SMB shares, but I am worried about malware on the secondary network getting access to the SCALE server. On the primary network, I'm very careful with whatever I do, but that's not necessarily always the case with everyone on the secondary network, and as noted, it's not just people but the internet of things on the secondary network.

So, in my case, I think the best approach is a dedicated VM with the relevant shared data and a dedicated interface to the secondary network.
 

Patrick M. Hausen

Hall of Famer
Joined
Nov 25, 2013
Messages
7,776
You can use a bridge on the secondary network to connect the VM without the TN host having an IP address on that network at all. Just a layer 2 connection or "vSwitch".
 

ChrisRJ

Wizard
Joined
Oct 23, 2020
Messages
1,919
I'm not at all worried about anyone in my home on the secondary network having access to all my SMB shares, but I am worried about malware on the secondary network getting access to the SCALE server. On the primary network, I'm very careful with whatever I do, but that's not necessarily always the case with everyone on the secondary network, and as noted, it's not just people but the internet of things on the secondary network.
In my view that is a somewhat flawed take on things. You seem to look at it as if the risk of malware is 0 with you and >0 with the others/IoT stuff.

I am in a somewhat similar situation here :wink: with me being considerably more careful than others. So yes, the risk is certainly lower for me. But I will never claim that there is 0 risk of me doing something wrong. Plus today you simply don't have to do something wrong to get your system infected.

In that sense you need to take the same counter measures for "your network/stuff" as for that where other people/things work. And if you do that anyway, it also makes sense to do things in a way that is as simple as possible. Complexity is a huge contributing factor for things going wrong. In case of a malware attack, there is not only the attack as a problem. In addition there is the complexity of the approach to mitigate things.

I have seen cases where a relatively minor problem in a data center was handled with a too complex approach. In one instance the result was that not only the application in question (specifically the connection between app server and database involving cluster software) stayed "down". But because someone misunderstood how a certain detail worked, the entire data center (or more specifically its network) was taken down by mistake.

If you are under attack there is a lot of stress. And then people do stupid things (I certainly have). So simplicity is your best friend!
 
Top