WIN_TUN v1.2: Tunnelling Ethernet frames through TCP/IP for Windows ################################################################### I. Introduction: The Problem ============================== With the appearance of peer to peer file sharing networks, bandwidth usage issues are becoming more and more serious for ISP's. Instead of upgrading their equipment to meet the growing demands for bandwidth, however, many ISP's are choosing bandwidth allocation software and hardware. If done carefully, this can be beneficial, but if not, it can impose ridiculous restrictions on channel usage for certain applications. This applies particularly to school/university networks, whose administration can pretty much do whatever they want with their channel without the risk of losing any customer base, and (as is the case on my network) without even providing any paid or third party alternatives. Bandwidth allocation software discriminates between different kinds of traffic based on protocol type (TCP/UDP), port number (port 80, which is used for Web browsing, is usually privileged), and even high level datagram/packet structure. While decent to enormous transfer rates are possible for Web browsing (for instance), applications like WinMX and KaZaA may experience the transfer rates of 500 bytes per second. Given this, most people have access to some other high speed, unrestricted channel (such as ADSL or cable modem), either at home or through a friend. If only they could use these from their location... II. WIN_TUN: A Solution ======================== 1. General ----------- WIN_TUN sets up and encrypted, compressed Ethernet tunnel. Ethernet, used on most home network, is a data link protocol (that is, a mode of transmitting data that underlies IP, the Internet Protocol). Ethernet adapters (AKA network cards) typically exchange data by the means of the Ethernet protocol. Different local area networks (LAN's), however, are interconnected only on the IP level using a different protocol. Therefore, Ethernet frames are purely local and are not forwarded from LAN to LAN, thus not allowing you to use anyone else's cable modem by directing your data link frames (blocks of data) across the Internet. In fact, if you could, you would be able to use whatever IP address and gateway (a machine that interconnects two or more LAN's on the IP level) available on a remote LAN -- because if you could forward your data link frames to that remote LAN (and have that LAN forward its data link frames to you), you would effectively become a part of that LAN, thus having access to all features that this remote LAN has. The Ethernet protocol would aid this matter greatly. While IP is almost exclusively point to point, Ethernet frames are essentially broadcast -- everyone hears everyone else. By setting an Ethernet adapter to what is called promiscuous mode, a machine is able to capture all Ethernet frames on the wire, whether they are addressed to it or someone else. Thus, all that is needed to interconnect two Ethernet LAN's on data link level are two machines (one on each network), some means of real time communication between the two (guess what... a TCP/IP connection on a privileged port works like a charm), and some software to pick up Ethernet frames on one network and forward them through that real time uplink to another LAN, where an identical piece of software would drop thus tunnelled data link frames onto the wire, and vice versa. WIN_TUN accomplishes this, giving its user the ability to use their local computer(s) as if it was (they were) a part of the remote LAN. This approach is also known as virtual private networking (VPN). 2. Data Compression; 3DES Encryption; The Confounding Socket; HTTP Wrapping ---------------------------------------------------------------------------- An Ethernet tunnel by itself, however, only solves half of the problem. As mentioned above, some of the bandwidth allocation software employed by ISP's uses high level protocol analysis to distinguish between HTTP traffic and KaZaA traffic, for instance, and apply bandwidth throttling techniques based on these results no matter what port or IP address the host TCP connection is established on. Essentially, this is accomplished by pattern matching, especially during handshake/connection buildup phase. Therefore, if one is to forward data that is classified as low priority over an Ethernet tunnel, one has to camouflage it to make sure that the real structure of the forwarded traffic remains undetected. One has two options here: either to scramble the bits around to make the traffic look like random junk, or to masquerade as legitimate prioritized traffic. WIN_TUN takes the first approach by default, but can be configured to use the second approach as well. By using data compression (applied first) and encryption (applied second), it makes the structure of the tunnelled traffic practically unrecognizable to an outside observer with tcpdump. While this requires significantly more computational overhead than simply forwarding Ethernet frames, in many cases that allows for _higher_ transfer rates than without data compression (by a factor as high as 1.9 for plain text or HTML data). WIN_TUN uses zlib data compression library. The compression is done on a per frame basis; higher compression ratios could have been achieved if the frame capture input had been buffered into larger chunks, but this would have also introduced increased connection latencies. Additionally, WIN_TUN can pretend to be a legitimate HTTP server (or client) transferring GIF files back and forth, thus allowing its user to fool some of the more advanced QoS devices (since HTTP traffic is usually given high priority). The encryption hides the remaining structure of the underlying traffic and the tunnelling protocol itself. Not only that, but also the encryption keys are changed per each frame transmitted. An encryption key for each frame is picked at random from 128 possibile variants. On the receiving end, an appropriate decryption key is bruteforced (that is, picked by systematic trial and error). (The Confounding Socket concept by Michael Piatek). There is a connection handshake, but it looks just like the rest of the tunnelled traffic and is indistinguishable from it. There are approximately 6 * 10^12 possible successful handshakes (would have been much more if I used a better random number generator) per password per set of keys. There is only 128 possibilities for failed handshakes, but to even get one, the attacker needs to have the right keys. Of course, the set of keys has to be the same on both end points for the communication to be possible and stable. You can always generate a new key file, which I recommend you transfer to the other machine by some means other than Internet, like a floppy disk. The encryption used is triple DES, so unless someone gets ahold of your keys (_do not_ share WIN_TUN directory through KaZaA and change keys immediately if trojaned), it will not be worth their time and effort to try and find out what you were sending through the tunnel. 3. Client and Server Modes; Challenge/Response Authentication -------------------------------------------------------------- The same WIN_TUN executable can run in either client or server mode. As always with TCP/IP, there is a server that listens and a client which connects, but once a tunnel is established, the communication is symmetric. In server mode, WIN_TUN is smart enough not to accept all kinds of irrelevant connections as tunnelling sessions and start sending out your LAN traffic to any kiddo with a port scanner (not that they would make much out of it anyway). The authentication is challenge/response based; the probability of successfully impersonating a client by sniffing a login is around 2 * 10^-13, without valid keys, and even then one could only send previously sniffed encrypted frames without any knowledge of what they contain. The server will go back to accept mode if a connection or authentication falls, and is resilient to login floods (10 second login retry delay); to my best, I tried to make sure that it contains no unchecked buffers at least in my code (not sure about libdes, zlib and WinPcap). For all practical purposes, by itself it's not a security hole on your network -- again, unless you share your key files and passwords in KaZaA, and unless the system you are running the server on is vulnerable by the means of open TCP sockets themsleves (that is, one whose device drivers could be attacked by sending certain data, like in unpatched Windows 95/98/ME). Careless setup can make it a big security hole for both networks, however -- we will cover that later. The client will fail authentication on decryption error (server has wrong keys), connection error, or reception of reject string. It will also wait indefinitely on authentication. But if a connection falls any time for any reason, it will keep trying to reconnect. In short, you do not have to babysit either client or server -- unless either zlib, libdes, or WinPcap decide to crash, like I had with WinPcap v2.3 on Windows XP. 4. Bandwidth Control --------------------- WIN_TUN supports bandwidth cap for the entire tunnelling session on either client or server side. By establishing one, you can make sure you do not attract too much attention by enormous amounts of traffic that looks like gibberish. 5. Ethernet Switching ---------------------- Last but not least, WIN_TUN acts as a transparent two port switching bridge, meaning that it will only forward packets that need to be forwarded over a TCP link; that is, if both machines (which transmitted and received the frame) are on the same local network, the frame will not be forwarded as there is no need to. This is particularly useful on heavily congested networks whose enormous local traffic would otherwise fill up any TCP/IP channel in a fraction of a second. This does not take effect immediately as WIN_TUN needs some time (and frames from local network) to learn the addresses of local machines. If a destination Ethernet address in a frame has never been heard of previously, the frame is forwarded by default. The address will be learned as soon as the machine in question transmits; since most of the communication on an IP network is bidirectional, this will usually not take long. Beware, however, that broadcast and multicast frames are always relaid to the remote network (as there is no way for WIN_TUN to know for sure that an address matching a multicast mask is not present on the remote LAN). Use point to point connections on both LAN's whenever possible. If you move a machine from local segment to remote, WIN_TUN will detect it and update its address tables as soon as that machine transmits, which means that you may want to initiate a connection from that machine (rather than to it) first. III. The Distribution ===================== The following files are included in this distribution. File Name Size Description ------------------------------------------------------------------------------- SOURCE The WIN_TUN source code, WinPcap and libdes headers KEYS.CFG 3072 A set of sample encryption keys for tunnelling LIBDES.DLL 54784 libdes encryption library, portion of SSLeay v0.9.0 README.TXT 53826 User documentation WIN_TUN.EXE 34848 The WIN_TUN Windows console executable v1.2 ZLIB.DLL 53248 zlib data compression library v1.1.4 IV. Usage ========== 1. Networking Concepts ----------------------- Modern networks utilize several layers of communication. From bottom to top, the operation of each next layer relies on that of the previous one, in a stack fashion. This is known as the OSI Network Model, its simplified version is in Figure 1. +===============+ # Applicaton # +===============+ # Transport # +===============+ # Network # Figure 1. The OSI Stack. +===============+ # Data Link # +===============+ # Physical # +===============+ In the context of a typical Ethernet LAN, the physical layer is the wiring. The data link layer is the most basic protocl to transmit chunks of data (frames) over the wiring. The network (IP) layer is a higher level protocol that packetizes the data streams and can operate on a variety of underlying data link layers, not merely Ethernet; it is used to interconnect networks with different data link layers. All these layers are unreliable; data may get lost or corrupted in transmission. Transport (TCP/IP) layer provides reliable data streaming support bu retransmitting chunks that get lost, and defines standardized means of establishing communication sessions (known as sockets, or connections). Finally, most application programs rely on these TCP/IP streams to transmit data. Application layer is data structuring that gets transmitted over TCP/IP and is defined by each application (Web servers and Web browsers, for example, utilize an application layer protocol knowns as HTTP). Encapsulating lower level data and transmitting it over higher level layers (turning things inside out in a sense) is referred to as tunnelling. WIN_TUN tunnels the Ethernet data link layer over the TCP/IP transport layer (more precisely, over its own private application layer protocol). The data link frames are transmitted over a TCP/IP connection to a remote LAN where they are dumped back on the wire. There can be other (not as widespread) transport layers operating over IP (UDP for example), just as there may be other network layers working on top of Ethernet (for instance IPX). WIN_TUN has an advantage over SOCKS proxies and applications such as Loophole, HTTPort, and GNU HTTP Tunnel in that it can relay all of these layers (everything that uses Ethernet) rather than just TCP/IP connections. 2. Network Setup ----------------- The most straightforward (and the lousiest) network setup to use WIN_TUN with is approximately like in Figure 2. All boxes inside a LAN are interconnected using Ethernet data link layer; the topology does not matter. GW is a local gateway -- a machine that connects a LAN to the Internet on IP (not data link) layer. At home, this is typically a router. At school or work, this is usually some designated machine, perhaps with evil fire wall and/or bandwidth shaping software/hardware installed. In any case, you should see gateway address listed, along with your own IP address and subnet mask, as you type "ipconfig /all" on any Windows box in command line. Let us assume that LAN 2's Internet access is restricted, while LAN 1 has unrestricted access, and you want to use boxes on LAN 2 as though they were on LAN 1. +======================+ +======================+ # +-------+ +-------+ # # LAN 2 +-------+ # # | Box 1 | | W_T | # # +---------+ W_T | # # | | | Box 2 | # # | ETH | Box 1 | # # +-----+-+ ++------+ # # | +-------+ # Figure 2. The # ... | | # # +---------+-------+ # Basic Setup. # ... |ETH |ETH # # | ETH | Box 2 | # # | | +----+ +--+-+ ... | | # # LAN 1 +-----+---+ GW +===Internet===+ GW | +-------+ # +=================+====+ +====+=================+ Now recall that as you tunnel between two LAN's, the two LAN's become one. That implies that you want to set up your IP configuration settings on the LAN 2 boxes you are planning to use to match those of LAN 1. In Control Panel, find Network/Configuration, select TCP/IP protocol bound to (indicated by arrow, or nothing if only one adapter) your Ethernet card, click Properties/IP address. Punch in your IP address manually; it must be unique on LAN 1 and match its subnet mask (read more about IP if you do not know how, but for a subnet mask of 255.255.255.0 and gateway of 192.168.0.1, for instance, the IP address can range from 192.168.0.2 to 192.168.0.254). Enter subnet mask and, in the Gateway tab, the gateway address (that for LAN 1, of course), and finally, the DNS servers name (copy gateway and DNS server addresses from any machine on LAN 1, only pick a different host name). If your router requires you to give access permissions to new machines, be sure to do so once the tunnel is up. Box 2 on LAN 1 will run WIN_TUN in server mode. Box 1 on LAN 2 will maintain its current IP address and subnet mask (to be able to connect through the Internet) and establish a tunnelling session to LAN 1, Box 2. Now LAN 2, Box 2 can use its new IP settings and access the Internet through the unrestricted gateway on LAN 1. Note that the setup is symmetric -- you could just as well set up a server on LAN 2, Box 1, and connect from home with LAN 1, Box 2, but the problem is that the restricted LAN 2 gateway may be a NAT gatweay (use private IP addresses for all LAN 2 machines that are not valid for the outside world, and translate these to public ones on outbound connections) or not allow incoming connections. Home routers are actually NAT routers too, but you have the advantage of being able to configure those, so be sure to set up port forwarding to the machine that will run WIN_TUN server on whatever port number that the server will listen on (default is 80), and use your external IP address when conneting to WIN_TUN server. Note that LAN 2 does not have to have two separate boxes. It can be just one box with two different network cards (TCP/IP bound to each), where the first, non-default, true local IP address is bound to the first one (which is used to establish a tunnel), and the second, default protocol (you can set default/ non-default somewhere in TCP/IP settings tabs), is bound to the second one and is used for all other connectivity. AFAIK, the second network card does not even have to be connected to anything (I may be wrong on this). You will need to set up WIN_TUN to _capture_ frames on the second network card, and to _listen_ (set up a server) on the IP address bound to the first one. You can even bind two TCP/IP protocols to the same network card, use one of the protocols to tunnel, and another one for everything else. Note, however, that if LAN 2 represents your entire school network, the setup given in Figure 1 is very insecure. Basically, you allow everyone in the school into your home LAN and to use your home Internet channel, as well as to listen to your traffic unencrypted (remember, Ethernet networks are broadcast). More, if your home LAN provides any broadcast services such as DHCP (which almost any router provides), you _will_ cause problems, for both yourself and your school network, since these services will conflict with those provided by your school network itself. You also give yourself away by this foreign traffic on LAN 2. For this case, here is an example of a much more secure setup. +======================+ +==========================+ # +-------+ +-------+ # # +=======+==============+ # # | Box 1 | | W_T | # # # W_T | LAN 3+-------+ # # | | | Box 2 | # # # Box 1 +------+ Box 2 # # Figure 3. # +-----+-+ ++------+ # # +--+----+ ETH | # # A LAN # ... | | # # +==+===========+=======+ # inside # ... |ETH |ETH # # |ETH ... # Another # | | +----+ +----+ ... # One. # LAN 1 +-----+---+ GW +===Internet===+ GW | LAN 2 # +=================+====+ +====+=====================+ Within your school LAN 2, you set up your own LAN 3 of 2 machines. Box 1 kind of acts like a gateway between LAN 3 and the Internet, but not really, because it provides no connectivity on IP level (be sure to disable any and all routing on this box, NT based systems may have it on by default). Box 1 has 2 network cards, one of them has LAN 2 IP address and is used for the tunnel connection, the other one is connected (by a crossover cable, for instance) to Box 1 and has LAN 1 IP address, as does the second network card on Box 2. In this setup, Box 2 does not even know that it is on LAN 2 since it is totally shielded from all LAN 2 traffic, and, no less important, LAN 2 is shielded from LAN 3 and LAN 1 traffic save for one encrypted TCP/IP connection running from Box 1 outwards, while to your home ISP it appears as if all your traffic originates from a single machine which is in reality your router. Unlike Figure 2, this setup gives LAN 2 and (in case of a home router) your ISP administration no unambiguous means of detecting the presence of a tunnel: no foreign IP addresses, no unregistered MAC's, no bogus DHCP services, no unreachable WINS names, no interfaces listening in promiscuous mode. Unless, again, you attract too much attention with enormous amounts of traffic. Now to a minimal secure setup. LAN 1 does not even have to have a router, nor multiple machines -- just a box with a network card, which may be plugged right into your cable or DSL modem (CM). +==========================+ # +=======+==============+ # # # W_T | LAN 3+-------+ # # # Box 1 +------+ Box 2 # # Figure 4. A # +--+----+ ETH | # # Minimal Secure # +==+===========+=======+ # Setup. +-------+ # | ETH ... # | W_T |ETH +--+ +----+ ... # | Box 1 +----+CM+===Internet===+ GW | LAN 2 # +-------+ +--+ +====+=====================+ WIN_TUN both listens and forwards frames to/from this single interface. If you have a hold of multiple IP addresses on your home ISP's network, you can use a couple of extra ones for your Box 1 and Box 2 (on LAN 3 now), otherwise you set up internet connection sharing (ICS) or some other good NAT on your home Box 1 on that same Ethernet interface, and use the corresponding private IP addresses on your school LAN 3. Note, however, that this scheme can also create a lot of private IP traffic, but now on your home ISP's network (depending on whether or not your DSL or cable modem is smart enough not to forward it there). WIN_TUN is smart enough not to pick up its own forwarded frames and send them back (which would create an avalanche of traffic and eventually fill up your channel), and it is also smart enough not to forward the traffic intended for local machines only (thus acting as a 2 port Ethernet switch), so it can be safely run to both tunnel and capture on the same interface. As said above, just be sure not to "mix" IP address spaces on large networks, as in Figure 2; that _will_ cause problems. If you join two networks as in Figure 2, be sure that all boxes (except the WIN_TUN tunnelling interface and the gateway on LAN 2) are on the same IP subnet. If it is within your control, use the setup in Figure 3 whenever possible (isolate the tunnelled data link layer) for security and compatibility reasons, even if LAN 2 then consists only of the gateway and the tunnelling interface of Box 1. Or, better yet, run WIN_TUN directly on the gateway if it is a Windows box. The tunnelling interface can be anything that supports TCP/IP, even a PPP dialup, while the capture interface must be Ethernet. 3. System Requirements ----------------------- a) A Win32 based operating system (Windows 95/98/ME, Windows NT/2000/XP) b) 16 megabytes of system RAM (the program itself uses about 4) c) A 486 CPU with floating point support (Pentium II recommended for fast transfer rates -- compression/decompression takes time and introduces lag, as does key bruteforcing. On a Pentium II 350 MHz CPU, the lag introduced is about 5 milliseconds, on slower systems that will be more significant) d) WinPcap of at least version 2.3 installed (can be obtained at http://winpcap.polito.it/). Version 3.0 or above is needed to be able to use any available Ethernet device for capture (with v2.3, you can only use some first one) e) An Ethernet network card with installed drivers f) A fully configured TCP/IP network connection g) (Windows NT/2000/XP only) An administrator access, or a privilege to open Ethernet interfaces in promiscuous mode 4. Command Line Interface -------------------------- WIN_TUN is a command line console application. You run these things by bringing up a command prompt, changing to the folder that contains the program using the CD "" command, and typing the name of the executable (in this case WIN_TUN.EXE) followed by a space and the list of command line parameters (also separated by spaces). The following is a detailed explanation of command line parameters and their options. You can also run WIN_TUN.EXE with no parameters to display the usage summary. General syntax: WIN_TUN.EXE <-l | -k | -addr [IP]:[port] [options]> Meaning: You can run WIN_TUN in three ways: either WIN_TUN.EXE -l, or WIN_TUN.EXE -k, or WIN_TUN.EXE -addr [IP]:[port] and all subsequent options. Below is the explanation of each parameter. Required parameters: -k This will generate a new file of 3DES encryption keys. The file is overwritten if it exists. A reference key file is already included with WIN_TUN distribution package, but _everyone_ has access to those keys as a result, so they are not terribly secure. Once you generate the key file, copy the file KEYS.CFG on a floppy disk and transfer it to the counterpart host, where it should be placed in WIN_TUN folder (overwriting the original file). -l List the Ethernet interfaces that can be used for data link frame capture. The devices are numbered; names and descriptions (WinPcap v3.0 only) are listed next to the numbers. These numbers can be used to specify a capture device with the -if parameter (see below). -addr [IP]:[port1][,port2] Specifies the IP address in dotted decimal form (example: 192.168.0.1) and the port number(s) on which to listen (if in server mode) or to which to connect (if in client mode). If you omit the IP address, WIN_TUN will use all IP addresses of your local machine (which is _not_ what you want when you run a client). If you omit the port number, WIN_TUN will use 80 (which is the HTTP port otherwise used for Web browsing and is usually open and privileged even on restricted networks). Specifying port2 will make WIN_TUN run in dual connection mode. In this mode, one connection is used for incoming traffic only, and the other is used for outgoing traffic only. It is designed to "fool" those QoS devices that watch send/receive ratio per connection and/or piggybacked ACK's to determine the type of traffic. The dual connection setting has to be the same on both client and server (i.e. if the server is set up to run in dual connection, the client must be also, and vice versa), otherwise the authentication will fail. Use dual connection mode only if you have to, since doing so opens a good opportunity for a MITM attack, as well as produces additional overhead. Optional parameters: -if Specifies the Ethernet interface (by number, obtainable using the -l parameter above) whose data link layer frames to relay. Default is 1 (which happens to be whatever device that WinPcap finds first). The interface must be Ethernet and openable in promiscuous mode for the tunnel to function. -bwc Limit the total tunnel transfer rate to bytes per second, for both transmission and reception. -s Run in server mode (attempt to bind to the IP:port specified by the -addr switch and listen for an incoming connection). If this switch is not specified, WIN_TUN will run in client mode (attempt to establish a connection to the IP:port specified by -addr). -pw Specifies the password to authenticate clients with (if in server mode) or to authenticate to the server with (if in client mode). The password is case sensitive and may consist of up to 1508 non-zero characters. -nc Disables the data compression of the sent data. Use this to speed things up on slower systems. Note: This disables compression, but not decompression; if the data received is compressed, WIN_TUN has no choice but to decompress it. To disable compression entirely, this option must be used on both server and client. -v Runs in verbose mode. Various troubleshooting and debugging information as well as minor warnings will be printed. For example, you can see what Ethernet addresses are being added to and removed from the address table. -q Runs in quiet mode: does not show console, but logs output to WIN_TUN.LOG instead (where x is a number), showing errors as message boxes. In this mode, the program is normally invisible to the user except in Task Manager and does not process any user input or system messages. To quit the program running in quiet mode, you need to either locate it in Task Manager and kill it, or reboot your system. -m Enables HTTP masquerading. Every encrypted frame sent will be wrapped in an HTTP request or response and a GIF image framework. This is intended to fool some QoS devices that check traffic structure by pattern matching. Only enable this feature if you have to (since enabling it by default adds unnecessary overhead and reduces throughput). -p :[p][,m] Connect to WIN_TUN server using an HTTP proxy with IP address and port number specified. If port number is omitted, 8080 is used. The proxy must not require authentication and must allow CONNECT command on WIN_TUN server IP address and port. Most proxies only allow CONNECT on SSL ports (try to run your WIN_TUN server on port 443 and/or 563). The mode (m) parameter is only effective in dual connection mode. 1 means use proxy for sender connection only, 2 means use it for receiver only, and 3 (default) means use it for both. -d This switch allows you to dump the incoming TCP traffic (which actually gets received over a TCP connection, without yet having been processed by WIN_TUN) into a file whose name is given. The file will be overwritten if it exists. The switch is mainly for debugging and research purposes, given how hard it is to find a good sniffer for Win32. Examples: WIN_TUN.EXE -addr :677 -s -pw 2xmSg&eRt5;sV -if 2 -bwc 16384 -v Sets up a service on all local addresses and port 677, sets the password to 2xmSg&eRt5;sV, the bandwidth cap to 16 Kbytes/sec, relays frames from Ethernet device 2 once a session is established, and prints out debugging information. WIN_TUN.EXE -addr 134.180.12.52:443,563 -nc -p 148.233.111.232:80,2 Connects to a server running at 134.180.12.52, ports 443 and 563 (dual connection), uses the trivial password for authentication, disables data compression on outgoing traffic, and uses the proxy server 148.233.111.232 (port 80) for receiving connection only. WIN_TUN.EXE -k Generates new KEYS.CFG, replacing the original file if it exists. 5. The Source Code ------------------- WIN_TUN source code is included with this distribution in the SOURCE folder. It is an LCC-Win32 project (get the latest version of LCC-Win32 at http://www.cs.virginia.edu/~lcc-win32/). The files are relatively well documented. Feel free to make any modifications, and it would also be good if you share ideas. V. Questions and Answers ========================== Q: Is this software legal to use? A: When operated entirely within the United States, it should be legal to use provided that your Internet Service Provider(s) do not specifically prohibit running any bridging, routing, connection sharing, or proxy software. When the tunnel is to begin/end outside of the United States, export restrictions may apply (strong encryption is used). Closely read terms of service from both of your ISP's; you know the rules -- what is not expressly prohibited, is permitted. There may be different encryption laws in your country. Also, that you can use this software legally does not mean that you can traffic anything using it that is otherwise not legal; in fact, this is concealing evidence and is an aggravating circumstance if you are proven guilty. Consult your lawyer if in serious doubt. Last but not least, do not expect your provider to sit idle and do nothing if they find out that you are using half of their available bandwidth with this software, even if it is all legitimate; ISP's usually reserve the right to alter their network settings and/or deny service however they see fit. Q: Can I use WIN_TUN to interconnect more than 2 LAN's? A: Yes, you can chain multiple network segments with multiple tunnels. Use the network topology of your choice, but avoid making any loops. The bridge code used by WIN_TUN is not IEEE 802.1 compatible; in particular, BPDU and the spanning tree protocol are not supported. WIN_TUN can detect frames that it itself has put on the wire and avoid forwarding those, but if the frames came in by some other means than the instance of WIN_TUN in question (for example, by a different chain of tunnels), the frames will start going in circles, eventually causing a broadcast storm and filling up your TCP/IP channels. Not only that, but if your LAN's have any Ethernet switches, it will also poison their address tables and may disrupt connectivity for several minutes to several hours. For the same reason, do not use WIN_TUN to tunnel frames on the same physical LAN, and in particular, do not run two instances of WIN_TUN on the same machine that connect to each other via loopback and capture from the same device -- not even to test it. Q: Can a WIN_TUN server accept more than one connection? A: No, you must run a separate instance of WIN_TUN server for each possible client. Q: Can I run WIN_TUN as a service on my WinNT/2K/XP system? A: WIN_TUN does not have service mode (nor a service installer) by itself, but you can use programs such as ServiceInstaller to run it as a service. Q: Can I specify a host name instead of IP address? A: No, I did not implement that, and addresses have to be numeric. Use "ping " from the command line to reslove that host name into an IP address. Q: How come I can only use one of my Ethernet cards for capture in WIN_TUN? A: Install WinPcap v3.0 or above (the latest version can be found at http://winpcap.polito.it/). WinPcap v2.3 is missing an important routine that looks up all suitable devices. Q: I have my setup as in Figure 3 above and I want to use Box 1 to run some services other than WIN_TUN on LAN 3/LAN 1, but I have to set the TCP/IP protocol bound to LAN 2 network card protocol to be my default protocol (otherwise I cannot establish a tunnel), which in turn leads other services to use that protocol as well. A: Use ROUTE.EXE Windows utility to manipulate the IP routing tables. Basically, you want the tunnel connection to go through your LAN 2 gateway, and you want every other outgoing connection to go through your LAN 1 gateway. First of all, set your TCP/IP protocol bound to LAN 3 card to be the default protocol, and set your LAN 3 IP address and other info statically (do not use DHCP (automatic configuration) because it cannot be used until you have the tunnel established, which gives us a chicken and egg problem). Reboot when prompted. Then open a command prompt and type: ROUTE.EXE DELETE 0.0.0.0 This will delete all gateways. Then type: ROUTE.EXE ADD MASK 255.255.255.255 Here, WIN_TUN-Server-IP is the IP address of the tunnel server which we are going to connect to, and LAN2-Gateway-IP is the IP address of the gateway on LAN 2 (find it out by typing IPCONFIG.EXE /all prior to this whole procedure). This tells the IP driver that the path to WIN_TUN-Server-IP (and only to this single IP) lies through LAN 2 gateway. Next, add the generic gateway that everything else will go through: ROUTE.EXE ADD 0.0.0.0 MASK 0.0.0.0 Here, LAN1-Gateway-IP is the IP address of the gateway on LAN1 (again, find it out using IPCONFIG.EXE /all on any of the LAN 1 machines). Finally, launch WIN_TUN (the routing table changes may not take effect immediately and a couple of connection attempts may fail). You can put this sequence of commands into a .BAT file and drop it into your StartUp folder to be executed each time Box 1 reboots. Q: Can WIN_TUN be used as a two port Ethernet switch? A: Sure. You must have two Ethernet cards on the machine that you want to make a switch. Run one in server mode specifying loopback (127.0.0.1) as the IP address and make it capture from the first device, then run the second one as a client, again specifying loopback to connect to and make it capture on the second device. Disable data compression on both. Q: Why Windows? A: For one, there are already numerous Ethernet tunnelling applications for Unix; I do not know of any free, open source implementations for Windows. For another one, both of the machines that I initially ran this on used Windows, and this was not completely under my control. Q: How portable is your code? A: Threading, timing, dynamic library access, TCP error handling, and console manipulation, and frame send routine are Win32 specific. The rest of the code (core logic, sockets, pcap, and console I/O) should all be portable. Most of the native code is encased in functions so that these can just be implemented differently on a different platform, without having to sift through the rest of the code. Q: What third party code does WIN_TUN use? A: It uses WinPcap packet capture library, which is not supplied (download the latest version at http://winpcap.polito.it/), zlib data compression library v1.1.4, and libdes encryption library (which is part of the SSLeay package v0.9.0 and has been compiled for Windows using LCC-Win32). Q: What TCP ports should I use in order to obtain good transfer rates? A: Ports that are privileged on your LAN's gateway; the setup differs from LAN to LAN. Common service ports are usually privileged. Things to try (in order): 80 (HTTP, and WIN_TUN default); 23 (Telnet); 5190 (AIM/ICQ); 6667 (IRC); 443, 563 (SSL); 22 (SSH); 25 (SMTP); 110 (POP3); 21 (FTP); 53 (DNS); 8080, 3128 (HTTP Proxy); 1080 (SOCKS); 3389 (Windows Remote Desktop). Ports to avoid: 137 through 139 (NetBIOS, often firewalled); 1214 (KaZaA); 6699 (Napster/WinMX); 59 (DCC). Q: I get good transfer rates on HTTP, but I can't get anything decent with WIN_TUN, not even on port 80, not even with my high speed internet provider. Q: My LAN administrators blocked my home IP address. Q: I am having problems using the proxy feature. A: Your LAN gatweay may be deprioritizing unrecognized traffic, even on privileged ports. Try to use HTTP masquerading feature (-m switch) on both client and server. If your server IP address is blocked, find a public proxy with good transfer rates and use the proxy feature (-p). Note, however, that proxy support is implemented using the CONNECT command and requesting the proxy to act as a tunnel (HTTP masquerading merely adds appropriate headers and trailers to frames, but does not make the traffic strictly synchronous (request/response) and therefore cannot be truly proxied). Most proxies only allow CONNECT on SSL ports, which means that you have to run your WIN_TUN server on port 443. If you are getting 403 (Forbidden) errors while connecting through a proxy, the proxy does not allow CONNECT. Besides this, right now only public proxies are supported (no proxy authentication mechanisms are implemented). If you need to use proxy authentication or to produce true HTTP traffic out of WIN_TUN stream, use some third party HTTP tunnelling software (e.g. HTTPort or GNU HTTP Tunnel) together with WIN_TUN. When using this kind of wrappers, be sure to disable the WIN_TUN HTTP masquerading and proxy features (the wrappers add necessary headers on and packetize an arbitrary stream by themselves). You may also consider running WIN_TUN in dual connection mode while proxying one or the other connection only; if your LAN2 QoS is watching for send/receive ratio per IP (incoming or outgoing), this may help. Q: My LAN administrators banned my network card's Ethernet (MAC) address and I can't connect to anything at all now. Q: My LAN administrators banned my network card's MAC address and I cannot use any other network card unless they register its MAC address, which they will not do. A: Obtain a Realtek RTL8029x network card. That card has a programmable EEPROM that stores all the card's static data, including its Ethernet address. By using the RTEEPROM utility (http://www.ixbt.com/multimedia/live-to-live51/rteeprom.zip), also used to upgrade Sound Blaster Live! to Live! 5.1 and written by Evgeny Bogdanov (evgbog@ccl.ru), you can modify your card's MAC address to a different one if it gets banned. Do not use any MAC addresses that are already in use by other machines on your network at the same time (hint hint), or a big confusion would result. Q: So much pain in the neck? Are there not any programs already that do what yours does, without the hassle of setting up separate LAN's and routers? A: Of course there are, but most of them that are for Windows are either not configurable enough, not free, and don't you even dare to say "open source". Of course, if all you need is relay your static outgoing TCP/IP connections, you could just as well use Loophole, HTTPort, GNU HTTP Tunnel, or a SOCKS proxy. In fact, if all you need is relay your Web traffic, an HTTP proxy will suffice. But I have not seen any consumer level Windows software that can tunnel the data link layer; the closest I can think of is Windows NT VPN/PPTP, but it lacks configurability. So if you are thinking about things like hosting servers, UDP, IPX, Netware, or even Windows file sharing and network drives on LAN's with restricted Internet access, you must either switch to some Unix, or use something akin to WIN_TUN. But yes, it is pretty hard to invent a bicycle nowadays... VI. Credits ============ WinPcap Loris Degioanni http://winpcap.polito.it/ et al. zlib Jean-loup Gailly http://www.gzip.org/zlib/ Mark Adler zlib for Windows Alessandro Iacopetti http://www.winimage.com/zLibDll/ Gilles Vollant libdes/SSLeay Eric Young http://www2.psy.uq.edu.au/~ftp/Crypto/ LCC-Win32 Jacob Navia http://www.cs.virginia.edu/~lcc-win32/ The Confounding Michael Piatek http://www.mathcs.duq.edu/~piatek/ Socket WIN_TUN itself Pa3PyX http://pa3pyx.come.to/ pa3pyx87405703@icqmail.com Hardware and Jedidiah2S12 Testing VII. Revision History ===================== v1.0 * First Version v1.1 + Added quiet mode * Client (rather than server) initiates the stream, like in HTTP * Console input no longer requires the [Enter] key v1.2 * Client reconnect attempts will now recreate the socket (so that dynamic routing table and default protocol changes take effect without restarting WIN_TUN) v1.3 * All threads are now terminated before frame capture is stopped upon session close, hopefully to fix crashes in packet.dll on WinNT/2K/XP * HTTP masquerading support * HTTP proxy support (using CONNECT) * Dual connection mode support VIII.Terms of Use ================= You may use this software and its source code in any manner that does not violate the permissions (listed below) granted by the authors of third party libraries used in this software. The author disclaims all responsibility for any damage resulting from any intended or unintended use of this software. If you distribute modified WIN_TUN or its derivatives, you are recommended but not required (to avoid confusion) to indicate that WIN_TUN has been changed from the original version by changing either the program name, or its version number, or both. Bug reports and feature requests should be sent to Pa3PyX (pa3pyx87405703@icqmail.com). 1. WinPcap Copyright Notice ---------------------------- Copyright (c) 1999 - 2003 NetGroup, Politecnico di Torino (Italy). All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the name of the Politecnico di Torino nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS˙"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its contributors. 2. zlib Copyright Notice ------------------------- version 1.1.4, March 11th, 2002 Copyright (C) 1995-2002 Jean-loup Gailly and Mark Adler This software is provided 'as-is', without any express or implied warranty. In no event will the authors be held liable for any damages arising from the use of this software. Permission is granted to anyone to use this software for any purpose, including commercial applications, and to alter it and redistribute it freely, subject to the following restrictions: 1. The origin of this software must not be misrepresented; you must not claim that you wrote the original software. If you use this software in a product, an acknowledgment in the product documentation would be appreciated but is not required. 2. Altered source versions must be plainly marked as such, and must not be misrepresented as being the original software. 3. This notice may not be removed or altered from any source distribution. Jean-loup Gailly jloup@gzip.org Mark Adler madler@alumni.caltech.edu 3. libdes/SSLeay Copyright Notice ---------------------------------- Copyright (C) 1997 Eric Young (eay@cryptsoft.com) All rights reserved. This package is an SSL implementation written by Eric Young (eay@cryptsoft.com). The implementation was written so as to conform with Netscapes SSL. This library is free for commercial and non-commercial use as long as the following conditions are aheared to. The following conditions apply to all code found in this distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL documentation included with this distribution is covered by the same copyright terms except that the holder is Tim Hudson (tjh@cryptsoft.com). Please note that MD2, MD5 and IDEA are publically available standards that contain sample implementations, I have re-coded them in my own way but there is nothing special about those implementations. The DES library is another mater :-). Copyright remains Eric Young's, and as such any Copyright notices in the code are not to be removed. If this package is used in a product, Eric Young should be given attribution as the author of the parts of the library used. This can be in the form of a textual message at program startup or in documentation (online or textual) provided with the package. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the copyright notice, this list of conditions and the following disclaimer. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. All advertising materials mentioning features or use of this software must display the following acknowledgement: "This product includes cryptographic software written by Eric Young (eay@cryptsoft.com)" The word 'cryptographic' can be left out if the rouines from the library being used are not cryptographic related :-). 4. If you include any Windows specific code (or a derivative thereof) from the apps directory (application code) you must include an acknowledgement: "This product includes software written by Tim Hudson (tjh@cryptsoft.com)" THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. The licence and distribution terms for any publically available version or derivative of this code cannot be changed. i.e. this code cannot simply be copied and put under another distribution licence [including the GNU Public Licence.] The reason behind this being stated in this direct manner is past experience in code simply being copied and the attribution removed from it and then being distributed as part of other packages. This implementation was a non-trivial and unpaid effort. fclose(stdout);