First, I installed and configured the loopback adapter as described, setting it to use ip 222.222.222.222. Then, in PuTTY on the "Tunnels" dialog, I simply put the following in the "Source port" text box:Mike Beaton added:222.222.222.222:139
I found your 'Cheap Research' Samba tunneling solution on the web. Based largely on your solution plus Joe Conway's additional information, I have come up with a more complete description of what you have to do to tunnel Samba using PuTTY (http://lists.samba.org/archive/samba/2004-May/085358.html). It definitely works from at least one network location completely outside my local firewall and there is some additional useful information in there. Unfortunately, however (as indicated in questions at the end), it still does not work from all locations from which I can get a perfectly good ssh connection. I'm hoping somebody else will be able to provide the final pieces of the puzzle!
I have a Dell laptop, with a wireless and Ethernet interface. The following worked through the wireless.
I installed the loopback device, with an address of 222.222.222.222/24. This address was chosen because 1) it is routable, and unlikely to me used, 2) there will be no collisions with RFC 1918 address space, which is used a lot especially by traveling PCs, and 3) it is easy to type. The latter probably doesn't matter, since I should be able to add a host name to lmhosts and use that, but I haven't tried it.
On the loopback interface, I have Client for Microsoft Networks and Internet Protocol turned on. File and Printer sharing is off. Under the advanced/WINS tab, Disable NETBIOS over TCP. At present, LMHOSTS lookup is disabled.
Both the wireless and Ethernet interfaces have exactly the same settings, except NETBIOS over TCP is turned on.
putty tunnels 222.222.222.222:139 to remote
I wonder: has this been made intentionally hard, to suppress the use
of Unix servers? Probably not, but it certainly interferes with the
secure use of such servers.
Stunnel is more complicated than I would like. I does come with helpful
recipes for jailing it with chroot, which I will apply.
I tried using sslwrap on the server end of the connection, because sslwrap
is much simpler, and I already run several jailed copies of it. But there
was some interaction that made it fail with stunnel after a few seconds
of connection traffic, forcing reconnections and trouble.
In general, though, my server is more attack resistant, and I can implement
more functionality. I don't consider the services I want to reach
from the outside world to be robust enough to resist attacks by numerous anonymous
probers. This is why I used to jail a pop3 and samba server, and restrict
access to hosts on our local network. With an SSL processor standing in the
way, I feel more secure:
Scott P. Malinowski writes:
Microsoft VPN Tunnel using the gateway on the client machine for Internet
access (in advanced properties.) This gave me all of the exact
functionality as before just in a little more complex package.
As I mentioned above, I have not yet conquered their VPN tunnel stuff.
Discussion
It would still be nice if Microsoft made this a bit easier. A little syntactic
sugar would help a lot. Symmetric key tunneling using public tunnels
like SSL and IPsec are a better solution than trying to get the MS pptp
right. Probably the best solution would be an optional port:
\\photos.cheswick.com:543\ches
which would allow local tunneling software to listen to non-139 ports.
All you your solutions required the shutting off of Printer and File
Sharing. For some this is not an option [...]