Binding File Sharing to a specific hardware interface?

[svenmany]

The routes don't tell you what's being used for file sharing and screen sharing.

netstat -na -p tcp | grep 445
netstat -na -p tcp | grep 5900

The first will show the socket for the file sharing connection. The second will show it for the screen sharing session.

I ran a test that is almost identical to your setup. I connected two Mac's directly with ethernet but left them both connected to my normal LAN using WiFi.

There are two parts to file sharing: finding available shares and connecting to those shares. Port 445 is the port used to connect to the shares.

The network section in the Finder sidebar is using mDNS (bonjour) to discover servers and shares on all three of the mini's interfaces. (https://en.wikipedia.org/wiki/Multicast_DNS). Your Mac Pro is being discovered at three distinct IP addresses. If you run the program Flame (https://apps.apple.com/us/app/flame-services-browser/id325206381), you would see that. When you then open the share, your mini will choose one of those interfaces to connect on port 445. I suspect it picks the first in the service order in System Settings.

Screen sharing was a little more interesting. I use Apple's Remote Desktop application. Even when I searched for the computer by the ethernet IP address, it actually connected using the WiFi one. The only way I could force a connection over ethernet is to use Finder command-k with a URL like vnc://192.168.0.2.

If you don't want to use a firewall, you will have to find some other way to prevent Bonjour from advertising services over the switch interfaces. It's going to be hard if you want some services to be advertised with Bonjour and the file sharing ones to not.

 

[mattspace]

The routes don't tell you what's being used for file sharing and screen sharing.

netstat -na -p tcp | grep 445
netstat -na -p tcp | grep 5900

The first will show the socket for the file sharing connection. The second will show it for the screen sharing session.

What the response to those commands supposed to look like?

I ran a test that is almost identical to your setup. I connected two Mac's directly with ethernet but left them both connected to my normal LAN using WiFi.

What's the network service order for each of them?

There are two parts to file sharing: finding available shares and connecting to those shares. Port 445 is the port used to connect to the shares.

The network section in the Finder sidebar is using mDNS (bonjour) to discover servers and shares on all three of the mini's interfaces. (https://en.wikipedia.org/wiki/Multicast_DNS). Your Mac Pro is being discovered at three distinct IP addresses. If you run the program Flame (https://apps.apple.com/us/app/flame-services-browser/id325206381), you would see that. When you then open the share, your mini will choose one of those interfaces to connect on port 445. I suspect it picks the first in the service order in System Settings.

So you're saying that when I choose Go > Connect to Server in Finder, and explicitly connect to 10.0.0.1, which then causes the Mac Pro to appear in the Finder Sidebar, I can't be sure the actual filesharing is going to route along the Thunderbolt cable? Or from the other direction, when I ARD to 10.0.0.2, I can't know that the connection will be over Thunderbolt? In ARD's case, I'm not choosing the Mini from Bonjour options, I'm just configuring it directly by IP address.

Would my Mac Pro be making 10.0.0.1 available out over the Ethernet connection, despite it being a 192 address?

That sounds... odd - like what would be the point of connecting to a server via a specific address that I hard coded to one network interface type (or being able to direct connect to a NAS that also mutually connected to a switch), but then sending the traffic back and forth over a completely different non-dedicated interface? It would seem to completely invalidate the point of Thunderbolt Networking.

I should mention the mini is runing High Sierra, so it may do things a little differently to the more modern Ventura Mac Pro.

Screen sharing was a little more interesting. I use Apple's Remote Desktop application. Even when I searched for the computer by the ethernet IP address, it actually connected using the WiFi one. The only way I could force a connection over ethernet is to use Finder command-k with a URL like vnc://192.168.0.2.

If I go into bonjour scanning in ARD, the Mini comes up by its ethernet IP, however if I search the explicit IP, it shows it's 10.x address, and getting into on it shows the administrator IP as also being a 10.x address.

If you don't want to use a firewall, you will have to find some other way to prevent Bonjour from advertising services over the switch interfaces. It's going to be hard if you want some services to be advertised with Bonjour and the file sharing ones to not.

I might have to ring Apple :/

 

[svenmany]

I started answering your questions and then I got confused about what your goals are.

You wanted to stop file sharing from being available on the switch-side interfaces. Have you adopted a strategy for that or are you just trying to learn some networking stuff before you decide what to do?

You have computer A trying to connect to computer B. You are discussing how to use A so that it uses the correct interface or how to figure out if it's using the correct interface. But, I thought your goal was to control B so that it doesn't matter what you do on A, you'll always be forced to use the thunderbolt interface.

 

[mattspace]

I started answering your questions and then I got confused about what your goals are.

You wanted to stop file sharing from being available on the switch-side interfaces. Have you adopted a strategy for that or are you just trying to learn some networking stuff before you decide what to do?

Well I was just trying to get the infrastructure all connected up and plumbed first, then figure out the routing.

You have computer A trying to connect to computer B. You are discussing how to use A so that it uses the correct interface or how to figure out if it's using the correct interface. But, I thought your goal was to control B so that it doesn't matter what you do on A, you'll always be forced to use the thunderbolt interface.

There are three goals initially:

• Mac Pro to be able to manage the Mac Mini with ARD, and for that connection to exclusively happen over the Thunderbolt connection.
• Mac Mini to be able to access network shares served by the Mac Pro, and for that connection to exclusively happen over the thunderbolt connection.
• Both machines to conduct the rest of their networking - internet access etc over their respective Ethernet connections.

Effectively, I don't want the data traffic between the two machines to have to compete with their network traffic to the Internet.

*Edit* this may end up being moot, because the Mac Pro won't successfully enter sleep with the Mac Mini physically connected via Thunderbolt, even if File Sharing is disabled, so I may have to investigate options for a TB2 -> 10GB Ethernet adapter, and move the connection to the Mac Pro's second 10GB Ethernet port.

 

[svenmany]

There are three goals initially:

• Mac Pro to be able to manage the Mac Mini with ARD, and for that connection to exclusively happen over the Thunderbolt connection.
• Mac Mini to be able to access network shares served by the Mac Pro, and for that connection to exclusively happen over the thunderbolt connection.
• Both machines to conduct the rest of their networking - internet access etc over their respective Ethernet connections.

Even though you might abandon this goal, I'll address it. Just to make sure I'm not confused, these goals are unrelated to the original goal in your opening post. That goal was about restricting access to the switch-side interfaces on the Mac Pro and Mini. The goal you mention now is about prioritizing one interface over another based on how one initiates a connection to one Mac from the other.

First file sharing. If you run Finder/Go/Connect to Server and specify smb://ip address, then you'll use the interface that's on the same network as that ip address.

My direct ethernet connection is configured with 192.168.0.5 (in the role of your Mini) and 192.168.0.2 (in the role of your Mac Pro). When on the Mini and I enter smb://192.168.2, the direct ethernet connection is used for the file sharing. The output of "netstat -an -p tcp | grep 445" is:

tcp4 0 0 192.168.0.5.52009 192.168.0.2.445 ESTABLISHED

You can ignore other lines you might see with "LISTEN" or "TIME_WAIT" at the end. The line just above tells me that the direct ethernet connection is being use.

If I instead enter "smb://server name", then I get different results at different times. I've played with service order, but I don't see an immediate effect with respect to which interface is chosen. If I use the "Network" entry in the Finder sidebar, the result is the same - a seemingly random choice of interface (I'm sure it's not random, but I don't know what drives the choice.)

So, if you want to use a specific interface to connect from the Mini, then use the Connect to Server technique where you specify the ip address of the Thunderbolt interface of the Mac Pro.

Now screen sharing. The Apple Remote Desktop application is hard for me to control. I see no way to specify an IP address when selecting "Control" after selecting the server. The IP address shown in the server list seems somewhat random. Even if I do an explicit lookup by IP address of the server, I might see a different address in the list. And when I do select Control, it picks some address not under my control.

But, I can control which interface I use for screen sharing if I don't use ARD. If I use Connect to Server on the Mac Pro and enter vnc://192.16.0.5, then screen sharing uses the direct connection. This is entirely the same behavior I see for file sharing.

In conclusion, if you count on name resolution in any way, you probably won't have control over which interface is being used. If you use IP addresses, then you would.

As an aside (and continuing to beat a dead horse)...

If your goal is to have all communication between the two Mac computers use the Thunderbolt interface and you only want to allow outgoing connections from the two Mac's on the switch side, then this is all completely trivial to implement with the PF firewall. Even name-based connecting would work and use the correct interface.

On the other hand, if you want to be a bit more selective on the switch side in terms of what you block, then the firewall setup would be more complex and probably not what you would be comfortable with.

And another aside: I'm really skeptical that Apple will be able to help you with this, or even choose to do so. I've pursued technical questions like these with support and it's proven to be futile. They usual have far less knowledge than I do and only refer to documentation they find. They don't start with an understanding of the concepts and reason from there. That's certainly been my experience with level two support. They seem only to be equipped to handle technical issues with advertised functionality. Differentiating behavior by interface is nothing I've ever seen Apple talk about in their advertising.

 

[mattspace]

Even though you might abandon this goal, I'll address it. Just to make sure I'm not confused, these goals are unrelated to the original goal in your opening post. That goal was about restricting access to the switch-side interfaces on the Mac Pro and Mini. The goal you mention now is about prioritizing one interface over another based on how one initiates a connection to one Mac from the other.

No it was the same goal, just looking at the probem in different places - I figured that if I could shut off filesharing via Ethernet, the connection would just flow across the Thunderbolt link once I'd set it up with the appropriate IP addresses.

Hence the subject of the thread - I wanted to bind filesharing to a specific hardware interface: Thunderbolt.

First file sharing. If you run Finder/Go/Connect to Server and specify smb://ip address, then you'll use the interface that's on the same network as that ip address.

My direct ethernet connection is configured with 192.168.0.5 (in the role of your Mini) and 192.168.0.2 (in the role of your Mac Pro). When on the Mini and I enter smb://192.168.2, the direct ethernet connection is used for the file sharing. The output of "netstat -an -p tcp | grep 445" is:

tcp4 0 0 192.168.0.5.52009 192.168.0.2.445 ESTABLISHED

You can ignore other lines you might see with "LISTEN" or "TIME_WAIT" at the end. The line just above tells me that the direct ethernet connection is being use.

OK well I don't have it set up at the moment, but I was setting the Go To Server in the Mac Mini's finder to the IP address the Mac Pro had in it's Thunderbolt network - smb://10.0.0.1. but (and my scrollback doesn't have it any more) I'm pretty sure netstat was showing the connection to the 192.x.x.x address.

Looking back at my Mac Pro, whose scrollback does still have it for the ARD connection to 10.0.0.2, while the route command to the Mac Mini reports 10.0.0.2 is over the bridge0 interface, netstat for that time shows port 5900 mapped to the Mini's 192.x.x.x address.

I cut down the rest of your reply, not because I don't appreciate you taking the time, but because I don't want to waste yours - the lack of sleep when Thunderbolt is connected has really thrown a huge wrench in things, and TB2>10g ethernet adapters are no longer available (I don't know if chaining a TB2>TB3 -> TB3>10g will work).

I might be better off virtualising the stuff the Mini was doing, or plugging it directly to the Mac Pro only via Ethernet, and enabling Internet Sharing to give it network access.

And another aside: I'm really skeptical that Apple will be able to help you with this, or even choose to do so. I've pursued technical questions like these with support and it's proven to be futile. They usual have far less knowledge than I do and only refer to documentation they find. They don't start with an understanding of the concepts and reason from there. That's certainly been my experience with level two support. They seem only to be equipped to handle technical issues with advertised functionality. Differentiating behavior by interface is nothing I've ever seen Apple talk about in their advertising.

Yeah, hence my "what's a Mac Pro?" comment. (Edit - that I might have posted on a different thread - Apple "support" staffer who didn't know what a Mac Pro was. That said, it is fun listening to people working from home in a different part of the world. My last support call, I could hear chickens in their yard.)

Cheers,

 

[svenmany]

OK well I don't have it set up at the moment, but I was setting the Go To Server in the Mac Mini's finder to the IP address the Mac Pro had in it's Thunderbolt network - smb://10.0.0.1. but (and my scrollback doesn't have it any more) I'm pretty sure netstat was showing the connection to the 192.x.x.x address.

Hmm. I do know that I've had both interfaces connected at the same time during my testing; so, netstat showed both. Also, if you're playing around trying different things, you'll certainly see remnants of connections in TIME_WAIT status on the mini for approximately two minutes after the connection was dropped. I don't know how else to explain what you remember seeing. Though, one possible explanation is that I don't know what I'm talking about; there's always something more to learn.

 

[mattspace]

Hmm. I do know that I've had both interfaces connected at the same time during my testing; so, netstat showed both. Also, if you're playing around trying different things, you'll certainly see remnants of connections in TIME_WAIT status on the mini for approximately two minutes after the connection was dropped. I don't know how else to explain what you remember seeing. Though, one possible explanation is that I don't know what I'm talking about; there's always something more to learn.

I have a sneaking suspicion Thunderbolt networking is a special case - that the sleep behaviour I'm seeing indicates it's only really tested for use as a migration tool, rather than permanent infrastructure.

Once I figure out if that's a solvable problem, I'll try it again.