# File Tunnel, and what happens when the transport is a file on a share > File Tunnel forwards TCP connections by writing the traffic into a file that the other end reads, which makes a shared folder, or an RDP drive share, a working tunnel between two hosts. It is a small C# tool with familiar SSH style flags, and it leaves several questions to the reader. **fiddyschmitt/File-Tunnel** — Tunnel TCP connections through a file - Repository: https://github.com/fiddyschmitt/File-Tunnel - Stars: 1,123 · Forks: 104 - Language: C# - License: MIT - Published: 2026-10-19 · Updated: 2026-10-19 · Language: en - Canonical page: https://hysenlabs.com/projects/fiddyschmitt-file-tunnel ## A tunnel whose transport is a file on a share File Tunnel is described in one line as a way to tunnel TCP connections through a file server, and the goal is to connect Host A to Host B when a firewall is in the way and both hosts happen to have access to a shared folder. The scenario is the reason the tool exists. A firewall between two machines blocks the direct connection, but the file server both sides can reach is not blocked. So the traffic is smuggled through the one channel that is open, and the tool is a small program on each side that agrees on which files to write and read. The second example in the documentation is a variation on the same idea with a different shared resource. There, Host A can only reach Host B over RDP, and the service to reach is 192.168.1.50:8888 on the far side of that RDP session. The trick is that an RDP client can share a local drive, so Host B can see a path into Host A's filesystem through the tsclient share, and the two file paths become the ends of the tunnel. What this buys you is that the tunnel works with no listening service on the server side. The file server is not a participant, it is just storage that both ends can reach, and neither end needs to be reachable from the other. The audience is administrators and support engineers dealing with awkward networks, and the tool ships as portable executables for Windows, Linux and Mac, so there is nothing to install on either host beyond the file itself. ## The mechanism: a TCP listener, a file, and a purge threshold The how it works section is three sentences long, and they describe the entire protocol. The program starts a TCP listener, and when a connection is received it writes the TCP data into a file. That same file is read by the counterpart program, which establishes a TCP connection and forwards the TCP data onwards. So one side is a listener that writes, the other side is a reader that dials. There is no handshake to speak of, no framing protocol and no acknowledgement, and the direction of the data flow is implied by which side is reading and which side is writing. In the examples, Host A writes to one file and reads from another, and Host B reads the first and writes the second, which is how each direction of the connection gets its own file. The one piece of real logic in the protocol is the bound on file size. To avoid the shared file growing indefinitely, it is purged whenever it gets larger than 10 MB. That single detail has consequences for how you use it. A purge is a truncation of the transport file, so the reader on the other end has to treat that as a signal rather than as data, and 10 MB is a ceiling on how much can be in flight between purges. It is a small number for a bulk transfer and a generous one for interactive traffic such as a remote desktop session, which is what the example in the documentation shows. The consequence for operations is that the transport files are the state of the connection. They accumulate data, they are truncated on a schedule, and they sit in a shared folder where other people may be able to read them. ## Running it: a listener with -L, a reader with --read and --write The command lines are short, and the flags follow the SSH convention closely enough that the mapping is obvious. The listening side of the firewall bypass example takes a local forwarding specification, a local port, a local address and a remote port and address, plus the two files. ```bash ft.exe -L 5000:127.0.0.1:3389 --write "\\server\share\1.dat" --read "\\server\share\2.dat" ``` That listens for connections on port 5000, forwards a received connection through the file tunnel and on to 127.0.0.1:3389, which is the Remote Desktop port. The counterpart on Host B only needs the read and write paths. ```bash ft.exe --read "\\server\share\1.dat" --write "\\server\share\2.dat" ``` No listening flag, no address, no port. Host B reads what Host A writes and writes back what Host A reads, and the two programs are now a TCP connection between 127.0.0.1:5000 on Host A and 127.0.0.1:3389 on Host B. The second example swaps the share for an RDP drive mapping, and the shape of the command is the same, only the paths change. ```bash ft.exe -L 5000:192.168.1.50:8888 --write "C:\Temp\1.dat" --read "C:\Temp\2.dat" ``` ```bash ft.exe --read "\\tsclient\c\Temp\1.dat" --write "\\tsclient\c\Temp\2.dat" ``` The tsclient prefix is the RDP client drive redirection, which is why the documentation tells you to make sure local drives are shared in the RDP client. The connection from Host A then goes to 127.0.0.1:5000 and ends up at 192.168.1.50:8888, which is a service on Host B's own network. ## Four forwarding modes: -L, -R, -D and the HTTP proxy The feature list reads like an SSH manual, and the resemblance is deliberate. The -L flag is local forwarding, and it can be used multiple times to forward numerous ports through the one tunnel, which is the point of a file transport: setting up the pair of files is the expensive part, so adding a second port costs almost nothing. Binding is the next flag to understand. To enable other computers to use the tunnel, you specify a binding address of 0.0.0.0, so a specification of the form -L 0.0.0.0:5000:192.168.1.50:3389 allows any computer on the network to connect to the tunnel and onward. The default is therefore the safer one, and changing it is a deliberate act. The -R flag is remote forwarding, and the semantics are inverted: it instructs the remote side to listen on port 5000 and forward connections through the tunnel and on to a destination reached via the local machine. That is how you share a server running on your own machine with other computers. The -D flag is dynamic SOCKS forwarding, just like SSH. A specification of -D 1080 starts a SOCKS4, 4a or 5 proxy on port 1080, with each connection dialled from the remote side, so applications can reach whatever the remote machine can reach. A bare -R 1080 with no destination is the mirror image, hosting the SOCKS proxy on the remote side and dialling out via the local machine. It handles TCP with the CONNECT method and SOCKS5 UDP with ASSOCIATE, and it has no authentication. The --http-proxy flag is the HTTP equivalent, starting an HTTP CONNECT proxy on a given port, dialled from the remote side, with a --remote-http-proxy variant that hosts the proxy on the remote side instead. It is CONNECT only, for HTTPS and any TCP tunnel, and it also has no authentication. Two of those four modes run a proxy with no authentication on it, which is the detail to keep in mind when choosing a port and a binding address. ## A wiki of supported file systems, and no mention of encryption The documentation points at a wiki for a full list of supported file systems, which is the sensible way to handle a question with a long answer. Anything that presents a file path to two processes can carry the payload, and the practical differences are about how the two ends see the same file, how quickly changes propagate and whether the platform locks the file while it is open. That last point is the one to check before choosing a location, because a file that the operating system holds open exclusively for one process cannot be read by the other end at the same time, and the tool's whole design depends on both ends touching the same file concurrently. The second gap is the significant one. The documentation describes writing TCP data into a file and reading it back, and it does not describe any encryption of that file, and it does not describe any authentication between the two ends of the tunnel. There is no shared secret to configure, no certificate and no key. That means the data crossing the share is the data you sent, in whatever form it was sent. For a remote desktop session over RDP, the session itself is already encrypted, so the file contents are ciphertext and the risk is lower than it first appears. For arbitrary TCP traffic, such as the service on port 8888 in the second example, the traffic in the file is whatever that service speaks, in the clear, and every account with read access to the shared folder can read it. The same reasoning applies to the transport files as a whole. They are a live copy of your traffic sitting in a directory, and the 10 MB purge only bounds how much is in the file, not who has read it. ## Portable builds, an MIT licence and a steady release line The tool ships as portable executables for Windows, Linux and Mac in the releases section, which is the right call for something you may end up running on a machine you do not administer, and the recent release history is steady. The listed versions are v3.5.4 on 2026-09-06, v3.5.3 on 2026-08-28 and v3.5.2 on 2026-08-11, and the last push was on 2026-10-19 with the repository not archived. The project is MIT licensed, so there is no constraint on using it internally, and the source is in the repository, which matters for a tool you are going to run on machines that are not entirely trusted. The repository layout is a Visual Studio solution. There is ft.sln at the top level, an ft directory for the program itself, ft_tests for the tests and ft_test_env for a test environment, alongside a build-release.bat and a build-release.ps1 pair of release scripts and the img directory holding the screenshots used in the documentation. The primary language is C#, and the presence of parallel batch and PowerShell release scripts suggests the author builds on Windows and ships the result to the other platforms. The wiki also carries the instructions for using a remote machine's internet connection through the tunnel, which is the SOCKS or HTTP proxy mode applied to the case where the remote side should be the one reaching the internet. The one thing to keep in mind when you deploy it is that it is a transport, not a security boundary, and the documentation does not claim otherwise. ## Conclusion Adopt File Tunnel if you need to reach a service across a network where the only thing two hosts share is a folder or an RDP drive mapping, because it turns that shared resource into a working transport without a server to deploy. Do not adopt it as a replacement for a VPN or a proper tunnel, since the documentation describes no encryption or authentication for the data written to the file, and a share you can read is a channel anyone on the share can read. Before you use it, check what permissions the shared file has and who else can reach the folder, purge the transport files after the session, and use the binding address of 127.0.0.1 rather than 0.0.0.0 unless other machines genuinely need the forwarded port. ## FAQ ### How does File Tunnel move TCP traffic through a file server? One side starts a TCP listener and writes the received TCP data into a file, and the counterpart program reads that file, establishes a TCP connection and forwards the data onwards. To stop the shared file growing indefinitely it is purged whenever it gets larger than 10 MB. ### How do I set up a File Tunnel between two hosts? On the host that listens, run ft.exe with a forwarding specification such as -L 5000:127.0.0.1:3389 plus --write and --read paths. On the other host, run ft.exe with the matching --read and --write paths, then connect to 127.0.0.1:5000 on the listening host. ### Can File Tunnel forward more than one port? Yes. The -L flag can be used multiple times to forward numerous ports through the one tunnel, since setting up the pair of transport files is the expensive part. ### Does File Tunnel support SOCKS and HTTP proxy modes? Yes. -D starts a SOCKS4, 4a or 5 proxy on the given port, dialled from the remote side, and --http-proxy starts an HTTP CONNECT proxy. The documentation states that neither carries authentication, and the SOCKS mode handles TCP with CONNECT and SOCKS5 UDP with ASSOCIATE. ### Is the traffic in a File Tunnel encrypted? The documentation does not describe any encryption of the file contents or any authentication between the two ends of the tunnel, and it states that the proxy modes carry no authentication. The transport files are a live copy of the traffic in a shared folder. ## Sources - [fiddyschmitt/File-Tunnel on GitHub](https://github.com/fiddyschmitt/File-Tunnel) - [Issues](https://github.com/fiddyschmitt/File-Tunnel/issues) - [License: MIT](https://github.com/fiddyschmitt/File-Tunnel/blob/master/LICENSE) - [README](https://github.com/fiddyschmitt/File-Tunnel/blob/master/README.md) - [Releases](https://github.com/fiddyschmitt/File-Tunnel/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fiddyschmitt-file-tunnel