Windows just doesn't like tunnels
February 25, 2011 2:58 AM Subscribe
What's the easiest way to implement a Windows SMB redirector?
I would like a little tool that lets me do on Windows what I can already do easily on any other OS - specify a remote SMB server by both IP address and port. Natively, Windows will not do SMB via any ports other than its choice of 445 or 139, and I'm sick of playing whack-a-mole with workarounds for the various Bad Things that Microsoft keeps adding to Windows to fsck up tunnelling SMB over SSH port forwarding.
What I have in mind is a little command line app that would let me do something like
netsubst servername -i IP -p PORT
This would work hand in hand with a driver? dll? that hooks into Windows as an SMB redirector, scanning a table of server names set up by netsubst instead of looking them up on the network in order to find out what to connect to. So after the netsubst I'd be able to do
net use X: //servername/sharename /user:username *
in the usual way, except that instead of Windows looking for //servername on ports 445 or 139 of whatever machines it finds on the LAN, it would go straight to address IP, port PORT; and if IP happened to be 127.0.0.1 and PORT happened to be something forwarded to somewhere else via ssh, it would All Just Work and I would no longer need to deal with the walls of stupid that Windows erects around access to localhost ports 139 and 445.
I figure what I need is something akin to the //vboxsvr guest addition that VirtualBox uses to do host file sharing, but rather simpler since it wouldn't need a full back end - in my ideal world, the only existing functionality I'd need to replace is the part that establishes the initial connection to the remote SMB server. But before I start tearing into the VirtualBox source code, can somebody suggest an easier way to get this done, or perhaps point me to Microsoft documentation on implementing SMB redirectors?
(cross-posted to Stack Overflow)
I would like a little tool that lets me do on Windows what I can already do easily on any other OS - specify a remote SMB server by both IP address and port. Natively, Windows will not do SMB via any ports other than its choice of 445 or 139, and I'm sick of playing whack-a-mole with workarounds for the various Bad Things that Microsoft keeps adding to Windows to fsck up tunnelling SMB over SSH port forwarding.
What I have in mind is a little command line app that would let me do something like
netsubst servername -i IP -p PORT
This would work hand in hand with a driver? dll? that hooks into Windows as an SMB redirector, scanning a table of server names set up by netsubst instead of looking them up on the network in order to find out what to connect to. So after the netsubst I'd be able to do
net use X: //servername/sharename /user:username *
in the usual way, except that instead of Windows looking for //servername on ports 445 or 139 of whatever machines it finds on the LAN, it would go straight to address IP, port PORT; and if IP happened to be 127.0.0.1 and PORT happened to be something forwarded to somewhere else via ssh, it would All Just Work and I would no longer need to deal with the walls of stupid that Windows erects around access to localhost ports 139 and 445.
I figure what I need is something akin to the //vboxsvr guest addition that VirtualBox uses to do host file sharing, but rather simpler since it wouldn't need a full back end - in my ideal world, the only existing functionality I'd need to replace is the part that establishes the initial connection to the remote SMB server. But before I start tearing into the VirtualBox source code, can somebody suggest an easier way to get this done, or perhaps point me to Microsoft documentation on implementing SMB redirectors?
(cross-posted to Stack Overflow)
Response by poster: In my experience so far, getting SMB working over SSH port forwarding is trivial (forward some port on the client to 445 on the server, smbmount, done!) except on Windows clients. This is not because of "all the ports it uses and all its crazy chatter"; it's quite specifically because (a) Windows doesn't have anything inbuilt to do SMB over any TCP port other than 445 or 139; (b) doesn't allow loopback connections on any 127.x.x.x address other than 127.0.0.1 without fartarsing about with additional loopback network adapters, and (c) grabs hold of 0.0.0.0:445 during system startup so you can't set up your own port 445 server on any local network interface.
Working around (c) does allow for perfectly reliable SMB-over-SSH on a Windows client; I do it routinely, and it works fine. But the actual workaround required keeps shifting, is too hard to script, and I'm sick of keeping up with it every time MS excretes another service pack.
The tool I want will work around (a) instead, which will make the other two not matter; and I can't think of a way MS could break it without also breaking a whole bunch of other stuff, which I don't believe they'd do.
Using a full blown VPN just feels like total overkill to me, and in the use case I have in mind it would require more political work than I'm willing to take on. Writing little device drivers in my spare time is not only easier for me, it's more fun.
posted by flabdablet at 7:28 PM on February 25, 2011
Working around (c) does allow for perfectly reliable SMB-over-SSH on a Windows client; I do it routinely, and it works fine. But the actual workaround required keeps shifting, is too hard to script, and I'm sick of keeping up with it every time MS excretes another service pack.
The tool I want will work around (a) instead, which will make the other two not matter; and I can't think of a way MS could break it without also breaking a whole bunch of other stuff, which I don't believe they'd do.
Using a full blown VPN just feels like total overkill to me, and in the use case I have in mind it would require more political work than I'm willing to take on. Writing little device drivers in my spare time is not only easier for me, it's more fun.
posted by flabdablet at 7:28 PM on February 25, 2011
I don't see how VPN is overkill. Its the recommended way to do SMB remotely. Heck, the ssh protocol is just as complex as any common VPN protocols. Sounds like you dont have the political capital to do the job the proper way. Oh well, good luck then on your workaround.
posted by damn dirty ape at 11:02 PM on February 25, 2011
posted by damn dirty ape at 11:02 PM on February 25, 2011
« Older In desperate need of dastardly deeds. | Professional offroad driving for power-chair user... Newer »
This thread is closed to new comments.
posted by damn dirty ape at 9:44 AM on February 25, 2011