Binding File Sharing to a specific hardware interface?

[mattspace]

I've been trying to find a solution, and haven't had any success do far - is there a way, through built-in or third party tools, to bind file sharing to specific hardware interfaces?

For example, I have two Macs connected via ethernet to a switch, and also using common Wifi that all the devices in the location use.

I want to run a thunderbolt cable directly between them, such that they can file share to each other over that cable, but the file sharing is not available / does not even show up to devices connected to the switch, or on the Wifi.

Suggestions appreciated.

 

[willowthewisp]

I've been trying to find a solution, and haven't had any success do far - is there a way, through built-in or third party tools, to bind file sharing to specific hardware interfaces?

For example, I have two Macs connected via ethernet to a switch, and also using common Wifi that all the devices in the location use.

I want to run a thunderbolt cable directly between them, such that they can file share to each other over that cable, but the file sharing is not available / does not even show up to devices connected to the switch, or on the Wifi.

Suggestions appreciated.

Assign a private IP-Adress to each TB-port (for example 10.0.0.1 and 10.0.0.2 with a subnet adress), then mount the volume or folder by hand depending on the protocol (smb or afp) using the “connect to” menu.
This connection is then your “private” network between two computers for file sharing.

 

[mattspace]

Assign a private IP-Adress to each TB-port (for example 10.0.0.1 and 10.0.0.2 with a subnet adress), then mount the volume or folder by hand depending on the protocol (smb or afp) using the “connect to” menu.
This connection is then your “private” network between two computers for file sharing.

Right, but that wouldn't make the resources unavailable to the ethernet network, merely password denied, right? I'm looking for an option that means its physically impossible to access shared resources, unless connected via Thunderbolt - so that other devices on the network won't see the shares as available, etc.

 

[willowthewisp]

Right, but that wouldn't make the resources unavailable to the ethernet network, merely password denied, right? I'm looking for an option that means its physically impossible to access shared resources, unless connected via Thunderbolt - so that other devices on the network won't see the shares as available, etc.

Set the rights/permissions for the specific folders in the control panel, specify only one user.
Or are you looking for a hidden/unvisible folder like in the pre OS X times ?

 

[mattspace]

Set the rights/permissions for the specific folders in the control panel, specify only one user.
Or are you looking for a hidden/unvisible folder like in the pre OS X times ?

Ideally I'd want it to be impossible, even with the username and password, to access shared resources unless connected via the thunderbolt link. That's why I was hoping there was a way to bind a share to an interface, or that there might be a third party tool to implement its own custom sharing connection.

I've found quite a few people asking this question online, but no answers, unfortunately.

 

[Nguyen Duc Hieu]

Ideally I'd want it to be impossible, even with the username and password, to access shared resources unless connected via the thunderbolt link. That's why I was hoping there was a way to bind a share to an interface, or that there might be a third party tool to implement its own custom sharing connection.

I've found quite a few people asking this question online, but no answers, unfortunately.

Set up a VLAN on Mac

Use Network settings to set up a virtual local area network (VLAN) on your Mac.

support.apple.com

Mac OS trunked VLAN Command line - Mervin Praison

VLAN Tagging in Terminal Note: [VLAN-TAG] = VLAN ID Optional: Set static IP address Set default gateway Delete vlan

mer.vin

VLAN Trunking

Multiswitch broadcast domains In the previous lesson, we explained that when a broadcast frame is received on any switch port, the switch forwards it out to all its other ports. Having that in mind, if we connect two default setting switches, as shown in figure 1, any broadcast frame received by...

www.networkacademy.io

 

[mattspace]

Set up a VLAN on Mac

Use Network settings to set up a virtual local area network (VLAN) on your Mac.

support.apple.com

Mac OS trunked VLAN Command line - Mervin Praison

VLAN Tagging in Terminal Note: [VLAN-TAG] = VLAN ID Optional: Set static IP address Set default gateway Delete vlan

mer.vin

VLAN Trunking

Multiswitch broadcast domains In the previous lesson, we explained that when a broadcast frame is received on any switch port, the switch forwards it out to all its other ports. Having that in mind, if we connect two default setting switches, as shown in figure 1, any broadcast frame received by...

www.networkacademy.io

To my eye, all of those options look to be describing setting up a virtual network over the common networking infrastructure. I want to run a separate network over separate hardware, and prevent one network from seeing that sharing is enabled on the other.

I don't want the private networking to physically travel through the switches the public network is using.

 

[mattspace]

This is the network topology I want to set up:

What I want to avoid is file sharing being available, or even acknowledged as existing through the switch.

 

[Nguyen Duc Hieu]

This is the network topology I want to set up:

View attachment 2372996

What I want to avoid is file sharing being available, or even acknowledged as existing through the switch.

Trunked VLAN is one of the solution.
The links I post were just suggestions for you to research more and execute to serve your specific needs. You already have the hardware available, how to setup the VLAN is up to you.

If you don't want to do your own research and study, the only solution left is hiring a network specialist to do the job.
The IT guys in my company can do that. He setup a private network, with private leased line via a separate router to connect to a remote server to submit FATCA report. All from a single LAN port on my laptop.
If he can do that, then so can another IT expert, same network hardware or separate network hardware is not the issue with the expert.

 

[mattspace]

Trunked VLAN is one of the solution.
The links I post were just suggestions for you to research more and execute to serve your specific needs. You already have the hardware available, how to setup the VLAN is up to you.

Right, but none of the examples I saw in the links you posted described what I want to do - they all seemed to rely on a thing I'm specifically trying to avoid - shared network infrastructure between private and non-private networks.

If you don't want to do your own research and study, the only solution left is hiring a network specialist to do the job.

That's why I'm asking here, to find out what I need to research further - if it can't be easily explained in terms of how I set it up for the network diagram I have, then it's unlikely to be explained in a way I can find myself.

All from a single LAN port on my laptop.

This is literally the opposite of what I want to do - I want to run two independent networks from two different ports on the machines, and have file sharing only enabled on one of them.

 

[Nguyen Duc Hieu]

I didn't suggest you an example, just a hint for you to research more.
Probably you are the first one to think about it.
I guess no one ever thought of doing it before.
Simply because if it can be done on 1 physical network interface, then I can't see why it will not be done on 2.

If you want to explain to a network technician about your request, then check my description below if it can be used with your diagram.
2 machine Mac A and Mac B, both has 2 LAN interface (normal LAN and Thunderbolt)
Both will be online 24/7; Both can be used by human at anytime of the day.
Mac A is used as workstation (A1) and file server (A2) at the same time.
File server A2 can only be seen by Mac B. Extra login ID and password needed for user on Mac B to log in and access file server A2.
(This is the hard part for novice users, probably need to change mindset)
Mac A1 still can access the file on the files server A2 as a local file. (Probably it would be easier if considering it as a small network with file server A2, 2 workstation A1 and B instead of thinking A1 to access the files as a local machine)

 

[cqexbesd]

I've been trying to find a solution, and haven't had any success do far - is there a way, through built-in or third party tools, to bind file sharing to specific hardware interfaces?

You have two main choices. Either get the server to bind to just one interface, or use a firewall to stop it receiving packets from other interfaces.

I don’t know if the built in SMB server in OSX allows you to configure which interface to listen on or not. If it does then it is probably by giving it the IP to bind to - just give it the IP you have to your thunderbolt interface.

Using a firewall would also work. Just denying incoming packets on all interfaces bar thunderbolt on TCP port 137 and maybe an extra one (you need to confirm that). That would prevent a file sharing session establishing.

Hopefully that gives you something to Google.

 

[svenmany]

If your goal is to completely isolate Mac 1 and Mac 2, giving them only access to each other and the internet, then a simple solution is using VLANs. You'd just get a switch that supports it. My network switch has 4 VLANs set up to isolate traffic at different levels of risk.

However, if you only want to limit file sharing but support other kinds of connectivity between the Mac computers and the other devices, then VLANs by themselves won't be enough.

It's a shame, but macOS doesn't use Samba for its smb implementation; Samba is so well documented. The "bind interfaces only" global parameter would do just what you want. However, the nsmb.conf man page on macOS does list an "addr" parameter. As usual, macOS is quite pathetic with its man page on giving thorough explanations. Perhaps you should play with that parameter and see if it does what you want. It's listed as a server level parameter

addr = "DNS name or IP address of server"

Personally I'd go the firewall route. I don't mean the macOS application level firewall that is controlled in System Settings. I mean the packet-level firewall that's also built into the OS. I would use Murus Firewall (https://www.murusfirewall.com/), which makes it very easy to configure it. Murus is not the firewall, just a tool that helps you configure it. I think it's a beautiful product. If you decide to go this route, I or maybe others on this thread would be happy to help you configure it. I just refreshed my memory on it, and it seems trivial to satisfy this exact use case. I do use Murus Pro, but I suspect the free version, Murus Lite, would be configured identically.

 

[mattspace]

If your goal is to completely isolate Mac 1 and Mac 2, giving them only access to each other and the internet, then a simple solution is using VLANs. You'd just get a switch that supports it. My network switch has 4 VLANs set up to isolate traffic at different levels of risk.

The specific goal is to have file sharing between the two macs occur on a hardware infrastructure (direct point-to-point thunderbolt cable) that is not shared by any other devices, and for the macs to be unable to conduct that sharing over the shared hardware infrastructure (ethernet).

That's the one, only and specific goal.

 

[svenmany]

The specific goal is to have file sharing between the two macs occur on a hardware infrastructure (direct point-to-point thunderbolt cable) that is not shared by any other devices, and for the macs to be unable to conduct that sharing over the shared hardware infrastructure (ethernet).

That's the one, only and specific goal.

So, unable to conduct "that sharing" through the switch, but able to do other types of sharing. For example, doing airplay from Mac 1 to your Apple TV. VLANs won't help you if you want that. Both the Mac and the Apple TV switch-side interfaces would need to be on the same VLAN for the airplay to work and that same VLAN would therefore allow the smb traffic. Perhaps @Nguyen Duc Hieu can shed some light on something I'm missing.

You need to find a way to prevent smb traffic on the switch interfaces of the two Mac computers. Just as @cqexbesd said, either ensure that the smb servers are not binding to those interfaces or prevent the smb traffic with a firewall. Your opening post asked about how to do the first one. Have you tried altering the settings in /etc/nsmb.conf to do that? Have you run "man nsmb.conf" and read that manual page? I have no idea if you'll have any luck with that. I trust Apple to sabotage most efforts to do something they didn't anticipate the average user would need. I don't know of any third-party tools that can help with this.

I do know that the built-in packet-level firewall approach is a trivial solution and Murus makes it easy to configure.

I don't know how to work with the more well-known application-level firewall of macOS to prevent the smb process from listening on a particular interface.

I have a license to Little Snitch. I don't see how it can help. You can limit the smbd process from accepting traffic "from" particular addresses, not "to" a particular addresses.

The makers of Murus also have an application level firewall called Vallum. I think it can do what's needed. I do have a license for it since I bought it together with Murus, but I don't have it installed. Consider https://help.vallumfirewall.com/index.php?chapter=ruleformat, where it shows that it can block by target address. It's kind of the same approach as a packet-level firewall except that the rule is for the listening process rather than just interfaces and ports.

 

[mattspace]

So, unable to conduct "that sharing" through the switch, but able to do other types of sharing. For example, doing airplay from Mac 1 to your Apple TV.

Pretty much - I'm happy to push content out over ethernet / wifi, I just don't want anything reaching in, or even having the possibility of reaching in.

For example if the thunderbolt connection goes squirrelly, I don't want to find out the machines have reconnected to each other over ethernet etc.

Ideally I was looking for a graphical tool to do it, hence as to whether there's a 3rd party app to configure the more obscure settings if they existed on the system, the way web server prefpanes used to configure the built in Apache.

 

[svenmany]

Pretty much - I'm happy to push content out over ethernet / wifi, I just don't want anything reaching in, or even having the possibility of reaching in.

For example if the thunderbolt connection goes squirrelly, I don't want to find out the machines have reconnected to each other over ethernet etc.

Ideally I was looking for a graphical tool to do it, hence as to whether there's a 3rd party app to configure the more obscure settings if they existed on the system, the way web server prefpanes used to configure the built in Apache.

That's slightly more restrictions to the Mac computers than I thought you wanted. For example, you might have wanted to allow your iPhone to Airplay to your Mac. But, if you want no ingress at all to your Mac computers (nothing "reaching in"), then the packet-filter is the way to go.

Murus is a graphical tool that would allow you to set this up.

The original thing you asked for, a way to have the smb server bind to just the thunderbolt interfaces, would not have protected your Mac computers from other things "reaching in" that are not smb traffic.

 

[svenmany]

I went ahead and installed Vallum and learned some things.

1 - I wouldn't use an application-level firewall to secure file sharing; it's hard to get all your bases covered. Vallum reported to me the various processes which were involved in file sharing. It was more than just smbd. So locking down smbd to one interface might not be enough for full security.

2 - Vallum reported the other things that were happening on my network that would be lost if I were to completely lock down an interface. "rapportd", which I've read manages Handoff, accepts traffic. I wouldn't want to lose that when working with my iPhone and Mac. There was also general incoming IPv6 Apple traffic that would support things like the Home app. And, I do sometimes screen share - that would be lost if I locked down the interface.

So, I would use the packet level firewall, configured with Murus to just lock down ports 137,138,139, and 445 on the switch-side interfaces. Generally the packet-level firewall is not running at all on our Macs unless we take steps to use it. Here's me, working in Murus setting up what I would want if I were to prevent file sharing on my wireless interface en0, but allow it on other interfaces.

 

[mattspace]

sorry, I've been busy with some other stuff - Realistically what I want to do is the specific thing of limiting filesharing to Thunderbolt.

I don't want to use firewalls - I'm really only interested in the exercise if I can have a simple on/off solution that is "unless cabled directly via thunderbolt, there would be no way to access shared volumes on the workstation".

For example, if there was a third party sharing tool, like WebDavNav that can be pointed directly at Thunderbolt, and ONLY thunderbolt, that's fine for me.

But, knowing how tenacious macOS is about connecting over any network to get to a resource it thinks it needs (which is what I've been fighting with for the past couple of days - a network share that won't stop mounting), I'm simply not willing to expose file sharing for these specific resources to the ethernet network. I can pull the thunderbolt connection without disrupting internet connectivity for either machine. Thats table stakes for it.

 

[svenmany]

sorry, I've been busy with some other stuff - Realistically what I want to do is the specific thing of limiting filesharing to Thunderbolt.

I don't want to use firewalls - I'm really only interested in the exercise if I can have a simple on/off solution that is "unless cabled directly via thunderbolt, there would be no way to access shared volumes on the workstation".

For example, if there was a third party sharing tool, like WebDavNav that can be pointed directly at Thunderbolt, and ONLY thunderbolt, that's fine for me.

But, knowing how tenacious macOS is about connecting over any network to get to a resource it thinks it needs (which is what I've been fighting with for the past couple of days - a network share that won't stop mounting), I'm simply not willing to expose file sharing for these specific resources to the ethernet network. I can pull the thunderbolt connection without disrupting internet connectivity for either machine. Thats table stakes for it.

The firewall solution is simple on/off after you've configured that one rule: "pfctl -e" (on) "pfctl -d" (off). But, OK, you don't want to use the firewall.

I looked at an example nsmb.conf file and "addr" parameter has nothing to do with what you want. Sorry I brought that up.

Some people recommend installing Samba and turning off the macOS native smb implementation. It's easy to do and would satisfy your requirements except that you want something graphical and I don't know what kind of tools would be available for that on the Mac.

Best of luck to you. Let us know if you find something you like.

 

[mattspace]

The firewall solution is simple on/off after you've configured that one rule: "pfctl -e" (on) "pfctl -d" (off). But, OK, you don't want to use the firewall.

Sure, but it relies on me trusting that the firewall works, and is secure. It's an elaborate security grill, for what remains an open door. I want ethernet to be a blank wall.

Some people recommend installing Samba and turning off the macOS native smb implementation. It's easy to do and would satisfy your requirements except that you want something graphical and I don't know what kind of tools would be available for that on the Mac.

Yes, I've encountered that solution. I'll have a look at it more thoroughly, as I can automate command line stuff via keyboard maestro - though ideally I'd want a notarised version of the package.

Best of luck to you. Let us know if you find something you like.

Thanks for your suggestions, willdo.

 

[svenmany]

Sure, but it relies on me trusting that the firewall works, and is secure. It's an elaborate security grill, for what remains an open door. I want ethernet to be a blank wall.

I'll never argue with intuition. You seem to be well informed. But, I do want to share my experience and intuition.

The PF firewall on BSD is an industry standard and used in corporate environments. I run an OPNsense firewall and it is based on FreeBSD - like macOS - and uses PF. The rules for the sharing restriction are as simple as they come - just one rule; it would be hard to make a mistake in configuring that and easy to test that the restriction is working. PF is open source and very, very, very heavily reviewed for vulnerabilities. I feel confident that it would be secure.

When I'm in a coffee shop I always enable PF to disable all incoming traffic. I don't trust that all my applications are secure, bug-free, or well controlled. They are reviewed for vulnerabilities much, much less than PF.

My intuition is that the firewall restriction is like a locked prison cell. Trying to control a daemon to listen on just one interface is like letting the prisoner free and asking them to behave. I'm trying to be funny, but that is a genuine representation of my intuition.

Sorry about beating a dead horse. I tried to resist adding this post, but it kept nagging at me that I had left it unsaid.

 

[mattspace]

I'll never argue with intuition. You seem to be well informed. But, I do want to share my experience and intuition.

The PF firewall on BSD is an industry standard and used in corporate environments. I run an OPNsense firewall and it is based on FreeBSD - like macOS - and uses PF. The rules for the sharing restriction are as simple as they come - just one rule; it would be hard to make a mistake in configuring that and easy to test that the restriction is working. PF is open source and very, very, very heavily reviewed for vulnerabilities. I feel confident that it would be secure.

When I'm in a coffee shop I always enable PF to disable all incoming traffic. I don't trust that all my applications are secure, bug-free, or well controlled. They are reviewed for vulnerabilities much, much less than PF.

My intuition is that the firewall restriction is like a locked prison cell. Trying to control a daemon to listen on just one interface is like letting the prisoner free and asking them to behave. I'm trying to be funny, but that is a genuine representation of my intuition.

Sorry about beating a dead horse. I tried to resist adding this post, but it kept nagging at me that I had left it unsaid.

Not at all, it's a good analogy, and I'll keep thinking about it. Much appreciated

 

[mattspace]

OK to update, here is where I'm at (all the cabling is set up), and I believe the problem I was trying to avoid is happening:

Workstation Mac Pro:

1. Ethernet to Router: DHCP static IP bound to Ethernet MAC
2. WiFi to Router: DHCP static IP bound to WiFi MAC
3. Thunderbolt to Mac Mini: Manual IP 10.0.0.1
4. Logged into my iCloud account

Legacy Mac Mini

1. Ethernet to Router: DHCP static IP bound to Ethernet MAC
2. WiFi to Router: DHCP static IP bound to WiFi MAC
3. Thunderbolt to Mac Pro: Manual IP 10.0.0.2
4. Logged into my iCloud account (for reasons of iCloud Drive)

The workstation has filesharing enabled, and only a single drive is shared.

On the Mac Mini, I can see the workstation in the Finder sidebar, and if I click on it, it will automount the entire workstation's filesystem, using the workstation's local credentials it's getting from iCloud.

I don't know how to tell what network interface that's using.

More importantly, I don't want it getting filesharing credentials via iCloud - I have a bad feeling the only solution to this is to remove the Mini from my iCloud account.

I can disconnect the auto connection, and manually set up an SMB connection to 10.0.0.1, and it will show only the single drive as available, but again, I personally don't know if that means I can be sure it's actually transiting the connection via the thunderbolt link.

I would also like to bind Apple Remote Desktop to the thunderbolt link, as the Mini only has gigabit ethernet and TB should provide for a more responsive experience, but whenever I try to configure connecting to 10.0.0.2, while ARD shows it as 10.0.0.2, if I get the attributes of it, it's showing its address as a 192.x - again, I don't personally know enough to know if I can attribute that to meaning the link is happening over the TB cable (I did my OS X Server Admin qualification with Apple ~19 years ago, so I'm very rusty from my sysadmin days).

So this seems to be where I'm at, and I imagine the next step is to waste several hours of my life trying to get Apple support to let me speak to someone senior enough that they know what a "Mac Pro" is (true story), and then see whether I can speak to someone who knows how to do the networking thing.


*edit* and FWIW signing the Mac Mini out of iCloud solved the login issue - now it only shows the login option for the dedicated filesharing user I created, and only mounts the specific drive I shared.

 

[mattspace]

OK, I think I've solved one part of it:

On the Mini:

route -n get 10.0.0.1 | grep interface
  interface: bridge0

route -n get [the ethernet ip address] | grep interface
  interface: en0

On the Mac Pro:

route -n get 10.0.0.2 | grep interface
  interface: bridge0

route -n get [the ethernet ip address] | grep interface
  interface: en0

So that would seem to indicate the appropriate traffic is transiting the appropriate cables. 🤷‍♂️