If anyone has suggested solutions, I would welcome them. If not, it would be nice to identify specific improvements that would solve the problems.
The file systems served have some sensitive files on them. The samba service is jailed such that a compromise should not threaten the server in a meaningful way. But if the samba server itself has a bug, or the Microsoft SMB authentication is weak or sniffed, the files would be exposed, and I would like to avoid that.
Therefore, the files are served only on an unrouted local network, to hosts with local addresses. An attacker would have to break into these hosts, and then gain access to the server. This is certainly not impossible, but it is quite a bit harder than a direct attack, and there are intrusion detection systems that are likely to detect the first break-in. Placing the samba server on the external network would be an unacceptable risk, opening it to a variety of attacks and probes.
I can't get it to work. The client already listens on port 139 (for serving files?) I can forward other ports from the client's localhost to the server, but there doesn't appear to be a way to tell the client to consult, say, "localhost:12345" for mapping a network drive. It insists on using port 139. It might be possible to turn off local file sharing, and perhaps the previous port 139 would not be there. The SMB protocol allows for such redirection, and I have a small simple safe program that can service it, but the remote firewall blocks nearly all outgoing TCP connections, including ports 137-139 and 445. Otherwise, I could simply answer the initial query with the localhost/port address that is tunneled through.
Some ssh implementations allow one to forward other local interfaces and ports. I am not sure putty can do this, and don't know how to create and use a dummy interface on the Windows client. I suppose I could insert a network card and use its address.
If there was a second computer available at the client's site, one could connect to its port 139, which would be forwarded through a VPN to the server, or redirected appropriately. But we don't have such a machine, and I am looking for a solution with the existing client host, even if it travels elsewhere in the world.
Also, the client's site has a firewall that appears to block the IPsec GRE packets. There are commercial IPsec implementations that carry the packets over UDP or TCP. I'd rather not tunnel with TCP for the TCP-over-TCP efficiency concerns, but am willing to do it if I must. The Cisco VPN offers this form of tunneling. I'd rather not have to buy a commercial VPN product for the PC---I am cheap, and trying to find a general solution here.
Microsoft does not enable PASV by default. In this mode, putty would have to listen to an assigned port, or ports, on the server and forward them back to the client. But though FTP tells the server which port to call back on, there is no application-level code in ssh on the server end that could tunnel a new server port back to the client. This becomes a muddle. Is there a solution here?
We can tell the Microsoft FTP server to use PASV, and then the server controls the ports used. This is better: we have good control of the server. But we have to pre-tunnel client ports to the server (I don't think the ssh server can ask for a new tunnel after the ssh session is set up.) This also becomes a muddle, and limits the number of data connections we can open at one time. A lot of file transfers would quickly exhaust our kludged up list of available ports, and they would end up in FIN_WAITs anyway.
I finally managed to get Win2K to stop listening to port 139. It's a long story that I don't understand very well, and involves installation of the loopback interface. netstat -a finally showed no port 139 listeners, which was required before it would let putty forward that local port. Putty has two ways to go with a local port: accepting outside connections (so it listens on 0.0.0.0:139) or not, so it listens on 127.0.0.1:139.
I can telnet to that port, and it gets tunneled. But "Map network drive" never reaches the port. Perhaps I need an entry in lmhosts...