Apple OS X SMB issues across VPN

[Dan Tappin]

On Oct 20, 2005, at 12:39 PM, Christopher R. Hertel wrote:

>>
>> I'll plead ignorance here.  I have no idea what the difference is or
>> how to find out.
>>
>
> http://ubiqx.org/cifs/


I had this explanation given to me:

>   it's basically whether the filesystem request packets are wrapped  
> in the old NetBIOS
>   headers.  NBT transport is on port 139 while the naked CIFS is on  
> 445.  Sadly
>   Windows will often try *both* and use whichever socket connects  
> first.  You
>   can check how things are connected on OS-X with:
>       netstat -an |grep 139 ; netstat -an |grep 445

xserve:~ admin$ netstat -an |grep 139 ; netstat -an |grep 445
tcp4       0      0  192.168.0.2.139        192.168.0.158.3183      
ESTABLISHED
tcp4       0      0  192.168.0.2.139        192.168.2.178.1381      
ESTABLISHED

...snip...

tcp4       0      0  192.168.0.2.139        192.168.0.131.1029      
ESTABLISHED
tcp4       0      0  *.139                  *.*                     
LISTEN
tcp4       0      0  192.168.0.2.445        192.168.0.190.1061      
ESTABLISHED
tcp4       0      0  *.445                  *.*                     
LISTEN
xserve:~ admin$

192.168.0.2 is my Xserve running Samba.


> If the traffic is untouched, that's good (and the configuration you
> describe should still provide data protection).
>
> I assume that the firewall systems are routing traffic between them  
> and
> all appears transparent to the machines on the local networks

Yes.. exactly.

> Do all of the clients point to the Xserve as their WINS server?
>
> Actually, that shouldn't be the source of the problem since you are
> getting access to the shares.  As I recall, the problem was incredible
> slowness once connected.  File transfers (reads and writes) were  
> okay, but
> directory listing was very slow.  Is that right?

Yes that is the problem exactly.  The local LAN 192.168.0.* is fine  
but the VPN LAN 192.168.2.* is awful.  They can see the shares but  
directory listings / transfers are unusable.

>>> - Can you capture a trace for us?
>>>
>>
>> I did this once before... I can't recall the procedure on unix.
>>
>
> There should be a MacOSX port of Ethereal or tcpdump...

tcpdump is standard on OS X but I'm at a loss as to which CLI options  
I need to add to get the data you are looking for.

Dan T