A solution is available here.

Tunneling Windows services to remote secured hosts

Here is an interesting security problem I have been fighting with. It involves Microsoft software and a firewall I don't control, and my efforts to fashion a secure solution with and in spite of these things.

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 Problem: tunneling Windows SMB service.

A remote computer, behind a fairly restrictive firewall, needs to access a local samba server. The samba server provides services on a local, unrouted network by a host that also has server routed network addresses.

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.

SMB over ssh?

The most promising solution would seem to be some sort of VPN tunnel from the client to the local network. One that is already working is ssh, and the user runs it regularly from the Windows XP client host, using putty. A fine solution would be to tunnel the local TCP port 139 to the server, and let SMB run over that, or let Windows XP (the client) go out through another port.

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.


IPsec is another obvious solution. The simplest would be an IPsec VPN link from client to server, with a shared secret key. This would be peachy, but the Windows client only supports certificate authentication, as far as I can tell. I would have to install a certificate service on the server, a bothersome and apparently error-prone task according to several web pages that describe it. Also, it is not clear that I could restrict the access to the single client PC I wish to support. Address-based authentication is not an option here.

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.

PPTP, perhaps tunneled through ssh?

Microsoft tunneling would be another solution. PPTP is available, and there is a server implementation available on the FreeBSD server host. But I don't trust the encryption on this tunnel (see Schneier et. al.), so it would need to be tunneled through ssh or IPsec. The latter runs into the same problems described above, but ssh seems like a possible tunneler, if PPTP can be convinced to run on TCP only. But early experiments seem to imply that Microsoft's PPTP link does not use just PPTP TCP packets on 1723, but reverts to GRE v1 packets after setup. The latter do not tunnel through ssh.

Other remote file access possibility: FTP

Microsoft supports FTP access as a remote file system, and I can certainly send the FTP control connection through putty with port forwarding. That has been tested and works. I also can implement the FTP server in a way that is as secure as the samba server---maybe more so since I understand the protocol better. The problem, as always, is the data channel.

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.

Web folders

Windows also supports connections to remote web folders. This is basically a simple file system implemented in HTTP. It would have to be served on port 80, or one of the few other ports (which?) that the remote firewall permits. If redirection is available, we could send further HTTP queries through the local tunnel, and that might be a good solution. I would like a small, simple HTTP server that handles the necessary file system commands. Of course, it would be jailed. Apache seems like over kill for this.

Discussion/wish list

If Windows XP allowed a port specification in "Map Network Drive" setup, this would all be easy. We would tell it to map to localhost:12345, and have putty tunnel that to the server. I wonder if there is a format or specification for that that I don't know that allows a port specification.

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 or not, so it listens on

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...

  • It would be nice if Microsoft's IPsec implementation supported shared secret keys. This is a fine solution for small communities of hosts, and very simple.
  • It would be nice to be able to specify a port on the "Map Network Drive" dialog box. Then localhost:xxxx would work just fine.