In classical, hardware based ethernet networking, network cards connect to other network devices via ethernet cable, radio signal, or some other medium. Since the network cards inside coLinux are virtual, the connections between them and other network devices are also virtual. The coLinux monitor provides the virtual hardware network cards to the coLinux OS, and uses TAP, winPcap, or Slirp to connect them to other devices. Here are some things a virtual network card might connect to:

  • MS loopback adapter (winpcap)
  • TAP virtual adapter (TAP)
  • a real ethernet adapter (winpcap)
  • SLIRP virtual adapter (slirp)

Possible communication paths:

  • coLinux virtual network card -> Slirp virtual network adapter -> LAN or Internet
  • coLinux virtual network card -> Microsoft Loopback adapter (using winpcap) -> Hosting OS
  • coLinux virtual network card --> TAP virtual network adapter --> Hosting OS
  • coLinux virtual network card -> physical ethernet adapter (using winpcap) -> LAN or Internet
  • coLinux virtual network card -> TAP virtual network adapter -> Microsoft software bridge -> physical ethernet adapter -> LAN or Internet
  • coLinux virtual network card --> TAP virtual network adapter --> Windows Internet Connection Sharing --> physical ethernet adapter -> LAN or Internet
  • coLinux virtual network card -> Microsoft loopback adapter -> Microsoft virtual bridge -> Wireless card -> LAN or Internet

Conection methods, in order of performance, fastest first: WinPCAP bridge, TAP connector, Slirp

Note: For some uses of coLinux, it is not necessary to configure networking at all. If this seems an extreme case, it's enough in some situations, like people who want colinux as an helper to develop web applications with Apache and/or PHP or to teste a MySQL, Postgres or even a Oracle database server configuration.

Note: The terms "adapter", "network adapter", and "network card" are interchangeable.

All of the network cards in a coLinux OS are, of course, virtual. Sometimes it is also convenient to create some additional virtual network card in Windows as well. The Windows loopback adapter is a virtual network card which comes with windows, and can be installed at any time. Use WinPcap to connect a coLinux virtual network card to a Windows loopback virtual network card. TAP virtual network card software, is bundled with CoLinux, and is another kind of virtual network card which can be installed in Windows.

The most simple way to get a coLinux OS on the network to use SLIRP, which is bundled with coLinux. A popular alternative is to to connect a coLinux virtual network card to a real network card using WinPcap, allowing coLinux to request IP address from a DHCP server, often a home router. Alternatively, connect a coLinux virtual adapter to a TAP virtual network adapter and use Windows Internet Connection Sharing (ICS) to share a network connection.

For performance reasons it is better to provision the coLinux OS with two virtual network adapters, one for direct communication with the Hosting OS, and one for connecting to a LAN or the Internet. This means that there are usually four network cards involved in the typical configuration, three of which are virtual. In the coLinux OS, one card is used exclusively to communicate with the Hosting OS. The other card communicates with a larger network, like a LAN or the Internet. Here is a list of the possibilities, which may be combined to get the necessary access:

ICS is a form of NAT. NAT traversal hinders some protocols and makes it difficult to access services running on the coLinux OS. However, if your network-provider (dial-up, DSL, or cable modem) supports only one IP-address, and you do not have a home router, running coLinux with NAT allows several private IP addresses to make use of that one one address you have been assigned.

Recommended Setup[]

The one-size-fits-all recipe for networking is to provision coLinux with two virtual adapters. One adapter connects to a LAN or the Internet, and the other adapter is a high-speed connection with the Hosting OS

  1. In the coLinux OS, configure one adapter exclusively for communication between Hosting OS. See TAP - Private Connection with Hosting OS
  2. In the coLinux OS, configure a second adapter for connecting to the Internet or a LAN. See Slirp (easy, slower, less problematic with wireless cards), WinPcap (more configuration required, faster, more problematic with wireless cards)


  • Disable any software firewalls running on the Hosting OS
    • Windows Firewall
      • Start -> Control Panel -> Network Connections
      • right-click on the TAP virtual adapter -> properties -> advanced -> Windows Firewall -> settings
      • select "Off (not recommended)" (Presumably, you aren't going to be attacking your XP system from coLinux)

[NB These instructions turn the firewall off for _all_ network adapters. This is probably not what you want. To turn off the firewall in _only_ the TAP adapter, go to TAP properties -> advanced -> Windows Firewall -> settings -> advanced, then turn the firewall off for the TAP adapter, leaving the others switched on (ticked)]

Provisioning Multiple Adapters for CoLinux[]

One strategy is to provision two network cards in Co-Linux, one for localhost communication and another for outside communication:

<network index="0" type="tap" />
<network index="1" name="Local Area Connection" type="bridged" />

In this scenario, eth0, the TAP-Win32 virtual adapter, would be configured to communicate with the Hosting OS, while eth1 would be configured for general network connectivity using WinPCAP bridge.

The value of the parameter "name" (name="Local Area Connection") must be changed to the actual name of your Hosting OSs network name, which can be looked up and renamed in the network configuration.

This scenario can dramatically accelerate X11 communications between coLinux OS and the Hosting OS. See TAP - Private Connection with Hosting OS

When booting up coLinux, the terminal window will display messages whether the bridged interface is listening packets. Assume a Debian package is running in coLinux, "eth1" needs to be manually added to /etc/network/interfaces (e.g. by using the built in editor "nano")

auto eth1
iface eth1 inet dhcp

Then use commands

ifup eth1

to bring up the interface and check whether it is working.


With Slirp, the coLinux OS can see other computers on the network, but no other computer can see it directly, not even the Hosting OS. However, it is possible to forward ports. It is also possible, of course, to launch X applications which target an X Server on the Hosting OS.

     +--------------------------+   internet connection    . . . . . .
     | Hosting OS               | <---------------------> .  internet .
     |    +-------------------- +                          . . . . . .
     |    |                     |
     |    |  slirp daemon       |
     |    |(outgoing calls only)|
         | coLinux |


The coLinux monitor itself acts as a DHCP server, granting the coLinux instance a private ip address and mediating all network communications. "Outgoing calls" from the coLinux box work as expected. Slirp can be configured to forward a port from the Host operating system to the Guest operating system. Other than this port forwarding capability, the coLinux Guest is invisible to the network. Using Slirp port forwarding, it is possible to ssh to the Guest, connect using vnc, etc. Port forwarding is not required to run xclients like xterm.

Slirp acts as a DHCP server to the coLinux OS, which gets an IP address like It can ping, which is the coLinux monitor on the Hosting OS. The coLinux monitor forwards all network communications.

Slirp is like having a firewall between the coLinux OS and the coLinux Hosting OS. The coLinux monitor is the firewall. It permits outgoing, but not unsolicited incoming traffic.

It is much slower than TAP or WinPcap, because everything happens in "user mode", but can be sufficient for most uses, and it works under almost any scenario. It is easy to deploy. There is no driver to install and the coLinux instance can be configured as a DHCP client. A common hiccup is that nameservers must usually be added to the coLinux OS in the file /etc/resolv.conf.

The big advantage is that it uses the normal Windows API to make connections and resolve addresses, so no routing or bridging is needed.

To use it in you XML config file, you just need this:

  <network index="0" type="slirp" />

Or, if you prefer the command line config (as of 0.6.2 version):


No parameters are needed and there are no optional parameters.

SLiRP with DHCP[]

Inside coLinux should eth0 configured with DHCP.

See IP Address - DHCP

Note: I'm not sure this is correct, because I've never gotten it to work with DHCP. I always use the static IP configuration below.

DHCP works with the recent release. One potential failure occurs when slirp DHCP proxy doesn't have the right values from the host. The symptom is the colinux guest fails to resolve external names with the slirp DHCP supplied address. Change the name server entry in resolv.conf to an external name server. If external names do resolve, simply reboot your machine and everything should be healthy at that point. If names do not resolve, you either have a broken external name server or a broken network configuration in colinux.

SLiRP with Static IP Address[]

If you can't run a DHCP client inside coLinux, use a static configuration.

IP address:
nameserver:  <primary nameserver of isp>
nameserver:  <secondary nameserver of isp>
nameserver:  <ip address of ICS server>

Not all of the above nameservers are required. Mix and match to taste.

See the following:

NOTE: SLiRP use non standard netmask. You must set it by config with or as IP address SLiRP can only ping to host, not outside to the world. Use apt-get, telnet or wget command to check your network from colinux to the world.

Forwarding Ports over Slirp[]

This must be done using command-line parameters or in plain text config file. The parameter syntax is:

eth0=slirp,<MAC>,tcp:<from Hosting OS port>:<to coLinux OS port>

Here are some examples:

  • vncserver: colinux-daemon kernel=vmlinux cobd0=fs_4095Mb cobd1=swap_512Mb mem=256 eth0=slirp,,tcp:5901:5901 root=/dev/cobd0
  • sshserver: colinux-daemon kernel=vmlinux cobd0=fs_4095Mb cobd1=swap_512Mb mem=256 eth0=slirp,,tcp:22:22 root=/dev/cobd0

Multiple ports can be separated with a slash. Example:

  • eth0=slirp,,tcp:5901:5901/tcp:22:22

Slirp FAQ[]

Do I have to set up port forwarding to run xterm?

No. Xclients typically do not require any incoming connection. They just need to connect out to the X Server. See XCoLinux


The NDIS driver is new in coLinux 0.7.4. It makes use of the NDIS programming API built into windows. It works in practice exactly like the WinPcap driver, just without third party network drivers.

It follows the same syntax in the configuration file as the winpcap driver, just use ndis-bridge instead of pcap-bridge


WinPCAP, the Free Packet Capture Architecture for Windows.

WinPcap is a software bridge.

WinPcap is a good choice for use with a router. Use this method if you are behind any sort of router, and want the coLinux OS to be seen by the network just as any other normal computer attached to the network. The coLinux OS will be able to use DHCP to request an IP address from the router, etc. In contrast to TAP, which provides another virtual network card on the Hosting OS, WinPcap lets the Hosting OS and the coLinux OS share the same network card.

This is a good method to use together with a private TAP network


  • Install WinPcap when prompted during coLinux installation.
  • Install WinPCAP, the Free Packet Capture Architecture for Windows.
  • The install automagically detects your operating system and installs the correct WinPCAP-driver. Follow instructions during install.
  • Add the following settings in the co Linux xml config file (or use command line arguments).
<network index="0" type="bridged" name="Local Area Connection" />

or, for a .bat file:

eth0=pcap-bridge,"Local Area Connection",

In the above line, change "Local Area Connection" to the name of your connection as reported by "ipconfig"

  • Note: : WinPCAP does work for wireless network connections, but you have to set the MAC-address, see below.

See the WinPcap page for details and troubleshooting.

The WinPcap driver[]

   |            |           
   | Hosting OS |    Virtual                          . . . . . . . .
   |            |     Cable       +-----+------+     .               .
   |            |<--------------->|  WinPcap   |     . Local Network .
   +------------+                 |  Virtual   |<--->.  or Internet  .
   +-----+------+                 |  Bridge    |     .   Connection  .
   |            |<--------------->|            |      . . . . . . . .
   |            |    Virtual      +------------+
   | coLinux OS |    Cable
   |            |

The WinPcap driver uses another existing connection and "injects" packects in it as if it were two connections. That way, it works as a low-level bridge between the colinux instance and an existing network card.

All packets sent/received by coLinux would reach all machines in the network.

The problems with this aproach is that it requires an existing network connection and may not work when you connect directly to your ISP, as they may refuse multiple IPs in the same line.

This can be solved by installing the Microsoft Loopback Driver and using it, but then it would be the same as the TAP driver.

The command line config (as of 0.6.2 version):

  eth0=pcap-bridge,"Connection Name",F0:12:34:56:78:9F

Or with the old XML config file would have a line like this:

  <network index="0" type="bridged"
           name="Connection Name" mac="F0:12:34:56:78:9F" />

or simply

<network index='0' name='XXXX' type='bridged'/>

Optional attribute

The "Connection Name" (parameter name='XXXX') must be changed to the Windows name of the adapter you wish to piggyback on, such as "Local Area Connection" (to get the name look into the windows network configuration. The name of the connection can be changed there too if necessary).

mac="XX:XX:XX:XX:XX:XX" specifies the MAC address of the interface in the linux side. It is recommended on bridged networking setups, where more than one Windows machine will be running coLinux on the same subnet. If not given, a random one will be generated.

Warning: On Windows Vista you need to run coLinux as administrator, or winpcap will not find any adapter.

Make sure the mac-address is different from the mac of your regular network interface. If you want to read why, read up on layer 2 networking.

(<zz85> This option seems to be the simplest for me. I'm on a network with a router as the gateway to the internet. DO NOT, like me at first, make the mistake of using the name of the virtual TAP network name.)

Since version 0.6.2 ="XXXX"= should be a substring of your network connection name (usually "Local Area Connection"). (In older coLinux versions (pre-0.6.2) "XXXX" was a substring of your network adapter's name.)

  • NOTE: Current versions are case sensitive for the connection name.
  • Either way I would recommend going to

`CONTROL PANEL > NETWORK CONNECTIONS > RIGHT CLICK THE CONNECTIONS > RENAME` and rename them to something more descriptive such as `ethernet`.

There should be at least one connection indicated as connected (when you're connected to the internet). This should be the network connection connecting you to the internet. Use its name to replace the _"XXXX"_ mentioned above.

  • NOTE: On some network cards (eg. Broadcom NetLink (TM) Gigabit Ethernet, Marvell Yukon Gigabit Ethernet controller), you need to disable Hardware checksumming (or Checksum offload, depending on your card) for the bridged network to work. Without disabling this, you can ping the coLinux guest system, but other connections from host fail (there aren't any problems with connections from other computers on the network to the coLinux guest though). This is a really hard problem to track down.
    • Sometimes, the Broadcom NetLink (TM) Gigabit Ethernet driver has an option for "Checksum offload", but disabling it does not fix the problem. However, setting "DisableTaskOffload" using regedit as described in Method 2 here can fix the problem.
  • NOTE: As noted before, hardware checksumming needs to be disabled on some cards (in my case a Broadcom NetXtreme 57xx) so host<->colinux TCP-connections work. The bad news: In my case, the settings for "task offloading" weren't visible, so I had to hack the .inf-file of the driver. Find your card in the .inf-file (PCI-Ids), locate the installation-section and add "ParamsNt" to "AddReg". Reinstall the driver with this inf and it should show up.
  • NOTE: On my Intel 82566DC Gigabit Network Card i had the same Problem. But the Option there has some other name. In German The Setting to deactivate is called "TCP/IP Abgabeoptionen". I think in English it would be something like "TCP/IP outgoing settings". There you should disable the four enabled settings and everything should work then. (matthias)
  • DAD: all kernels with IPv6 support have Duplicate Address Detection integrated. and you will get a warning message on the command window saying:
eth0: duplicate address detected!
eth0: duplicate address detected!
  • Keep this in mind when using the pcap-bridge option, because if DAD is activated it won't give your internal co Linux eth0 an IP address.
  • so if you have a ipv6 network and you are using the pcap-bridge option this will not work, unless you disable or kill DAD
  • duplicate address detected is fixed in coLinux 0.7.4, because new rule exclude our self as source mac.

Private Connection to Hosting OS via Loopback Adapters[]

In effect this approach creates a private connection (virtual network) between the coHost and the coGuest.
Building a virtual network for your coHost and coGuests has the following advantages:

  • in most setups it requires no hardware.
  • it eliminates dependencies on physical hardware, like having a working physical network connection to get virtual networking to work (as is required by a classic NDIS or PCap bridge).
  • the additional hop between the coGuest and the physical network used by the coHost allows for extra security measures (firewall on coHost).

Drawbacks are:

  • the additional hop could mean more complicated network setup, like configuring the coHost to function as a router.
  • no physical control over the network connection. eg. Yanking out a network cable will probably disconnect the coHost and coGuest from the internet but not from each other.

A number of methods are available to create a private connection (virtual network):

  • bridge to the already supplied Windows Loopback Interface (which is bound to IP address
    • This approach will limit you to using an IP address inside linux in the 127.x.x.x range. Which is semantically quite strange, but perfectly valid. Also this IP address range cannot be changed easily as with a Microsoft Loopback Adapter.
  • bridge to a new Microsoft Loopback Adapter.
    • Advantage of this approach over the one using the "Windows Loopback Interface" is that you will be able to change the subnet the host and guest live on easily.
    • Advantage over the TAP interface is that you can bridge as many guests as you see fit on the virtual adapter and they will all be able to communicate to each other and the windows host (if the network config permits this (same subnet etc.)).
    • Drawback is you need to install a new hardware device which requires administrative privileges on Windows.
    • An older blog post (October 2004) by DavidSklar describes troubles in setting up networking and ultimately uses a Microsoft Loopback Adapter instance to resolve the troubles. Although older, it is quite a nice in-depth how-to article.
    • AndrewRoth reports the Microsoft Loopback Adapter did not work in his setup and discourages using this kind of networking setup. Instead he recommends adding a TAP interface for every coGuest as explained #TAP.
  • using a hardware loopback adapter.
    • This approach is used primarily to overcome the disconnecting of coGuest an coHost when a network cable is removed from the physical network card.
    • Drawback of this approach is that it requires custom hardware.

Using the Windows Loopback Interface[]

In the coLinux config file use:


Using a new Microsoft Loopback Adapter[]

First you probably need to add a new virtual network interface (using the Microsoft Loopback Adapter driver). This is explained on numerous websites (Google Search).

NOTE: When inspecting the new network adapter it reports it operates at 10mbit. This is not true, after empirical research my setup maxed out at 200mbit (25MByte/s) when transferring a 50MB random binary file from the guest to the host (using apache -> wget) and the same in the opposite direction (using lighttpd -> wget).

As explained on this Microsoft knowledge base article, the virtual adapter will try to get a dhcp address and eventually will fail and assign itself a private IP address in the 169.254.x.x range. In a typical setup you will specify a static IP on the virtual Loopback adapter. For a guide how to change the ip address in windows see this knowledge base article. For simplicity sake we will use:

  • subnet 192.168.1.x
  • netmask
  • loopback adapter ip

Now you need to bridge the new adapter to the coGuest using the following directives in the config file:

eth0=pcap-bridge,"Microsoft Loopback Adapter"
# or
eth0=ndis-bridge,"Microsoft Loopback Adapter"

When booting the coGuest the eth0 interface (in Linux) will be on the same (virtual) physical net as the new Microsoft Loopback Adapter. So if we set use an ip address in the same subnet, the host(Windows) and guest (Linux) will be able to connect to each other.

Using the following commands we can test if networking works in this setup.

$ ifconfig eth0 netmask
$ ping
PING ( 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=128 time=0.000 ms
64 bytes from icmp_seq=2 ttl=128 time=10.0 ms
64 bytes from icmp_seq=3 ttl=128 time=10.0 ms
--- ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2010ms
rtt min/avg/max/mdev = 0.000/6.666/10.000/4.714 ms

Networking works when the ping command is successful.

Using a Hardware Loopback Adapter[]

DaveLynch uses a hardware loopback adapter primarily to overcome the disconnected bridges when the UTP connection is lost.

I use a different LoopBack connector when operating "disconnected" I have an RJ-45 plug with pins 1&2 tied to pins 3&6 respectively. Windows believes the network is alive and colinux and windows can connect. DHCP does not work - unless you have a DHCP server either under Windows or colinux.


Also see Bridging

Disable Promiscuous Mode[]

In order for the PCAP bridge to work with some wireless cards, coLinux has to use them in non-promiscuous mode. This can be done by adding 'nopromisc' to the command-line ethX arg, or by adding 'promisc="false"' to the XML config file.

  • My D-Link DWL-G122 needed the step above !

Ping the the IP address of the gateway from coLinux. If the wireless link link light indicates activity, see the use non-promiscuous mode, or possibly see Network#After starting coLinux, HostOS connection seems to go down

Enable Promiscuous mode[]

It might be necessary to force the wireless card into promiscuous (compatibility) mode.;EN-US;Q302348&ID=KB;EN-US;Q302348

Cards which might need to be forced into promiscuous mode:

  • Intel centrino 2200BG (reportedly solved by driver versions greater than

Have a look at With wireless, it might not be possible to bridge anything. Anyone has an idea why? Yes, here:

MAC address[]

Set this MAC address to the MAC address of your wireless card. This will make the wireless router accept the packets sent by Winpcap



+--+----------------+                         +-------------------------+---------+                  
|  |virtual adapter-|<----------------------> |-TAP virtual adapter     |         |                  
|  +----------------+    coLinux Monitor      +-------------------------+         |                  
|                   |                         |           Hosting OS              |                  
|     coLinux OS    |                         |        +--------------------------+      . . . . . . 
|                   |                         |        |physical ethernet adapter-|-----.  internet .
+-------------------+                         +--------+--------------------------+      . . . . . . 
                                               (connect these adapters using windows                 
                                               software bridge, ICS, etc.)                           

TAP is a virtual network adapter that installs on the Hosting OS. The coLinux OS network adapter can then connect to this virtual network adapter. Windows sees the TAP virtual adapter looks just like any other network adapter, and there are many possibilities:

  • Private Connection to Hosting OS: High-speed, connection between Windows and CoLinux (no outside network)
  • Windows Internet Connection Sharing: Windows ICS configures the Windows TAP adapter with a static address and provides a DHCP server that the coLinux OS requests an IP address from. Good choice when ISP will only assign one IP address and you don't have a home router.
  • Windows Software Bridge: Connect the TAP adapter and the real adapter to the Windows Software Bridge and let them communicate with the rest of the world exactly like two separate computers would. This is the logical equivalent of connecting two different computers to a hub or router. coLinux, for example, could get an IP address from an external DHCP server (like a home router).

After you create a virtual adapter on the Hosting OS with TAP, all the options of configuring a real ethernet adapter are available. A common method is to use Windows Internet Connection Sharing to share a network connection to a coLinux OS connected to a TAP virtual adapter.

Microsoft Software Bridge could also be used to bridge the TAP adapter to any other adapter. This has various applications, one of which would result in a setup which functions much like WinPcap. (Also ICS works fine with software bridged interfaces. You can share your internet connection with the bridge.)

  • Note: the windows firewall will interfere. Please add instructions

for re-enabling it.

Note: When you install a TAP virtual adapter in Windows and start coLinux, Windows might make a change to the network routing tables. It is necessary to undo this change. See Network#After starting coLinux, HostOS connection seems to go down


  • Recent releases of coLinux automatically install this for you so you may be able to skip this step.
  • Even when the installer has installed a single TAP device, the Add/Remove-Hardware wizard of Windows may be used to add second and subsequent TAP devices.

On MSWindows XP:

Control Panel -> Add Hardware -> Yes -> Add a new hardware device
-> Install from a list (Advanced) -> Network Adapters -> Have Disk
-> Go to the supplied TAP-Win32 directory and choose OemWin2k
-> Next -> Next -> Finish.

On MSWindows 2000:

Control Panel -> Add/Remove Hardware -> Add/Troubleshoot Device
-> Add a new device -> No -> Network Adapters -> Have Disk
-> Go to the supplied TAP-Win32 directory and choose OemWin2k
-> Next -> Next -> Finish.

On MSWindows 7: Because the TAP Adapter is virtual all of the Windows 7 intelligent routines which scan for real hardware will fail.

If the TAP driver is not listed in the Hardware Wizard you will need to select 'Have Disk' and locate the TAP driver installation files.

Control Panel -> Hardware and Sound
-> In 'Devices and Printers' section -> Device Manager

In Device Manager
-> Right Click on your computer in the tree (should be first item)
-> Select 'Add Legacy Hardware' from context menu

In the Add Hardware wizard 
-> Select 'Install the hardware that I manually select from a list (Advanced)'
-> Network Adapters
-> Manufacturer 'TAP-Win32 Provider (coLinux)'
-> Network Adapter 'TAP-Win32 Adapter V8 (coLinux)'
-> Next -> Next -> Finish.

On the Hosting OS, edit the "network" line of coLinux xml config file:

<network index="0" type="tap" name="Connection Name" mac="12:34:56:78:9A:BC" />

Or, for a .bat file:

  eth0=tuntap,"Connection Name",12:34:56:78:9A:BC

The name and mac fields are optional. If you don't specify the name parameter coLinux will use the first TAP device it finds. If you don't specify the MAC address in mac, a random one will be generated (in the range 00:FF:xx:xx:xx:xx).

Again, the connection name and MAC address are optional, so it can be just eth0=tuntap .

  • NOTE: Current versions are case sensitive for the connection name.
  • NOTE: If you use the option name, please rename the TAP connection without spaces. Some coLinux versions don't work with spaces in the name.

Trivial TAP/coLinux Debian network configuration[]

After failing to locate concise instructions on coLinux network configuration amid this lengthy catalog of the theory and relative merits of SLIRP, TAP, bridging and dual virtual adapters, I came up with an extremely simple method of network configuration using the TAP virtual adapter under Windows XP.

I use an MSI Wind U100 running Windows XP. I assume that you have a network adapter (in my case, a Wifi adapter) configured to use DHCP; the procedure below will work with static addresses if /etc/network/interfaces is modified as documented elsewhere. I also assume that you have installed coLinux under Windows along with the TAP virtual adapter (as described above), you are using a Debian kernel (mine is Debian-4.0r0-etch.ext3.1gb) and that you came to this page looking for the instructions that I am about to provide.

coLinux configuration file[]

The relevant line in my colinux.conf configuration file is


As far as networking goes, that's it for your colinux configuration file.

Windows ICS configuration[]

Configure Windows Internet Connection Sharing (ICS) on your wireless adapter in Control Panel->Network connections. Right click on your wireless adapter, select Properties, click the Advanced tab (without irony), and ensure that ICS points to your TAP adapter. To repeat details provided elsewhere, check "Allow other computers to connect through this computer's Internet connection" and select the TAP adapter in the "Home networking connection" box. Ignore the patronizing suggestion that you are configuring a mere "Home" networking connection and not the networking connection of some august institution.

Don't point the TAP adapter to your wireless adapter! As revealed by running the ipconfig command in a Windows command prompt window, I renamed my TAP virtual adapter "coLinux" from "Local Area Connection 6"; behold:

Ethernet adapter Wireless:
' '
       Connection-specific DNS Suffix  . :
       IP Address. . . . . . . . . . . . :
       Subnet Mask . . . . . . . . . . . :
       Default Gateway . . . . . . . . . :
' '
Ethernet adapter Local Area Connection:
' '
       Media State . . . . . . . . . . . : Media disconnected
' '
Ethernet adapter CoLinux:
' '
       Connection-specific DNS Suffix  . :
       IP Address. . . . . . . . . . . . :
       Subnet Mask . . . . . . . . . . . :
       Default Gateway . . . . . . . . . :

In Debian Linux[]

Your /etc/network/interfaces file should not mention eth0, except perhaps in comments. Despite what I think I've read on these pages, there was no way for me to see eth0 (ethx) in Debian when I set eth0=tuntap (ethx=tuntap) in my colinux config file. Instead, your /etc/network/interfaces file should include the lines

auto eth1
iface eth1 inet dhcp

(This assumes, as above, that you will obtain DHCP from the adapter configured to point to the TAP adapter. Otherwise you can configure a static address on your network.)

You're done! Now that you have a working network, you may to enjoy relating the theoretical discussions herein to something akin to practice.

TAP - Private Connection with Hosting OS[]

+---+--------------+                      +-------------------------+---+                                    
|   |first adapter-| <------------------->|-TAP virtual adapter     |   |                                    
|   | |    coLinux Monitor   |           |   |                                    
|   +--------------+       (TAP)          +-------------------------+   |                                    
|                  |                      |                             |                                    
|   coLinux OS     |                      |           Hosting OS        |                                    
|                  |                      |                             |     +-----------+                  
|  +---------------|                      |                             |     ||      . . . . . . 
|  |second adapter |                      +-----------------------------+     |  Router   |-----.  internet .
|  |   | <------------------->|   physical ethernet adapter |<--> |           |      . . . . . . 
+--+---------------+   coLinux Monitor    +-----------------------------+     +-----------+                  

Use this method to provide a high-speed private network between the Hosting OS and coLinux OS. This network will be completely closed to the outside world. A coLinux OS can be configured to use this network on one interface and to use one of the other methods for Internet connectivity.


  • Run X applications on this network, while using a separate network for Internet connectivity
  • High-speed. Communication does not make a round trip to an external network device
  • Always available, even when network cable is unplugged.


In the following example, a subnet of "37" is used. This is an an arbitrary number. If you already have a "37" network, it should be changed to something else. The hosts, "10" and "20" are also arbitrary.

On the Hosting OS[]

  • The TAP-Win32 Virtual Adapter should have the following properties:

Set the TAP-Win32 device properties - available from 'Configure' button on 'General' tab of connection. When Tap-Win32 Adapter properties window shows up, go to the 'Advanced' tab, select 'Media Status' item on the 'Property' list and set its 'Value' to 'Always connected'.

TCP IP protocol properties:

Ethernet adapter coLinux:

        Connection-specific DNS Suffix  . :
        IP Address. . . . . . . . . . . . :
        Subnet Mask . . . . . . . . . . . :
        Default Gateway . . . . . . . . . :    .   .   .

Note: Do not set the above default gateway on the windows side of the connection (leave it blank). Windows may lose internet connectivity if it is set.

  • Verify that X Server will permit a connection from the CoLinux OS:
$xhost +inet:

On Vista this doesnt work by default because the firewall blocks outgoing connections eg ping from colinux doesnt get reply. This can be solved by setting windows firewall to not monitor the Tap interface.

In the CoLinux OS[]

  • Create a new interface in /etc/network/interfaces. For example:

auto lo eth0

iface eth0 inet static

auto eth1
iface eth1 inet dhcp

Or, if you are using Gentoo, your /etc/conf.d/net file would look like:

# There should be no gateway="..." setting.
# The default file may contain one near the bottom.
iface_eth0=" netmask broadcast"

In the example above, no gateway was set because it is assumed that another gateway has already been specified for a different interface. Beware - If you have two networks from coLinux, make sure that the default gateway points to the network that has contact with the outside world! (check with route, or netstat -rn) To add a default specifically for this network (e.g., if you wish to bridge it), the following might work:

(route add -net gw eth0 OR)
route add -net netmask dev eth0
route add default gw

For Gentoo, try adding a line to /etc/conf.d/net that is like the following:

  • Set the Display
$export DISPLAY=

TAP with Windows Internet Connection Sharing[]

See Internet Connection Sharing (ICS)

TAP with Windows Software Bridge[]

Bridging generaly[]

A windows software bridge has its own MAC address. If the router is filtering on MAC addresses, it may be necessary to allow the MAC address of the Windows software bridge.

TAP with Windows Software Bridge on Windows XP[]

Note: I just spent about 3 days trying to get exactly this to work with my setup, it's just 5 minutes ago that I finally learnt that I am not totally dumb, but that trying to get the software bridge to work via wlan with my setup/NIC (intel based wlan chipset) is simply a no-go at the moment, for details you might want to check out:

So, if you happen to have an intel wlan chipset, you may want to first check that it's supported!

Someone more savy than me might want to incorporate this info here.

Some wireless chipsets are not able, or disallow spoofing of the mac address.
If it uses your mac address when it leaves, then it's either routed, or NATed.
To use bridging, it needs to leave the wireless with the mac address it had to start with.

Instead of using the Internet Connection Sharing DHCP server, bridge the TAP virtual adapter to the physical adapter and let coLinux get an address from a router with a DHCP server or directly from an ISP (if you have an ISP which will assign you multiple IP addresses).

Set up Windows Software Bridge (included in Windows XP, not Windows 2000)


The Microsoft Windows software bridge generates STP (spanning-tree protocol) packets. On a corporate network, STP packets will generally be construed as evidence that you have a router hiding under your desk. The network switches might be configured to immediately shut down your port. Instead, use Winpcap to bridge directly to a physical network adapter, or user Slirp.

Install a TAP Virtual Adapter. See Installation

Make the bridge

Control Panel -> Network connections
-> select the network interface that will be used for network-access,
then you select the TAP-Win32 Adapter so that both interfaces is selected.
(Use Control+click on both the interfaces).
Right-Click to get up the context-menu and select bridge connections.

This will create a new "Network Bridge" virtual interface and now Windows and Linux have independant access to the network.

Bridged, on vmWare running Windows XP SP2[]

I found that the above bridging methods did not work for a machine on VMWare running XP SP2 and could possibly work in native environments.
The following is my method that works with a DCHP network (on the Debian image running Colinux 0.6.3), but does not aquire an IP Address from the DHCP Server.

Step 1: Install WinPcap
Step 2: Install Colinux
Step 3: Update default.colinux.xml to point to HDD image (Note: I did not change the network config)
Setp 4: Configure Static IP Address. See IP address - Static
Step 5: On the Hosting OS, modify the tcp/ip settings of the coLinux network connection

Control Panel -> Network Connections -> Right click on the Colinux connection

Select "Status" Then click properties and select the TCP/IP protocol in the list and Click Properties. Ensure "use the following IP address" is checked and fill in the information the same as in /etc/network/interfaces click ok and ok again.
Step 5: Bridge the connections
Control and Right Click both connections and select "Bridge Connections" this will take a few moments
Step 6: Restart Colinux
The network should work and the apt-get facility should function properly

Note: This method only works obviously if there are not 254 machines on the IP range, ensure the IP you set is well above the possible number of machines using the DHCP on that range (i.e mine is 15). A botch fix but it works well.

Windows 7[]

See CoLinux networking on Windows 7

TAP with Proxy ARP[]

Another way is setup TAP as subnet of real network interface, enable routing and proxy arp in host. But there's no public tools manupulating Windows proxy arp entries.

IP Address - DHCP[]


Using DHCP, you can request an IP address assignement from a DHCP server. To do this, a DHCP client must be installed on the coLinux OS. Such a client is already installed in some, but not all downloadable coLinux filesystem images. Therefore, it may be necessary to first configure a static IP address, install a DHCP client, and then switch to DHCP.

DHCP Client Installation[]


apt-get install pump

If a network connection is not available, it is, of course, possible to install a DHCP client from other physical storage media.

Note: Using DHCP with Slirp, it is usually also necessary to add add nameservers. See DNS Nameservers



# file: /etc/network/interfaces
auto eth0
iface eth0 inet dhcp


# emerge dhcpcd

# nano /etc/conf.d/net

config_eth0=( "dhcp" )

Restart the network. See Restarting a Network Interface

Check Gentoo webside for more informations.

IP Address - Static[]

Note: If the Hosting OS and the coLinux OS are to be visible to each other, they normally should be on the same network. i.e., they should have the same network mask. and the same network number. See IP addresses and Network Masks

If you are using a TAP virtual adapter, the gateway should be the ip address of that adapter.


Example: Typical TAP Configuration

colinux:/etc/network#nano interfaces
iface lo inet loopback
auto lo eth0
iface eth0 inet static
   # gateway

Example: Typical Slirp Configuration

# file: /etc/network/interfaces
auto eth0
iface eth0 inet static

Add Nameservers. See DNS Nameservers


The Gentoo image uses DHCP out of the box. To change this to a static IP configuration, edit the text files /etc/resolv.conf and /etc/conf.d/net. For the latter, comment out the line

Edit /etc/conf.d/net, so it looks like this:

iface_eth0=" broadcast netmask"
# gateway="eth0/"

another suggested configuration is like this:

# nano /etc/conf.d/net
config_eth1=( " netmask" )
# routes_eth1=( "default gw" )

Example: Typical Configuration for Slirp

# nano /etc/conf.d/net

config_eth0=( " netmask brd" )
routes_eth0=( "default gw" )

Check Gentoo webside for more informations.

Add Nameservers. See DNS Nameservers

As of 2005-11-9, ( and I assume much earlier also) the Gentoo default root_fs is called "Gentoo-colinux-stage3-x86-2004.3" The file /etc/conf.d/net in this root_fs already has the coLinux changes for IP address and gateway IP address, so you will not need to edit. In my case, this is the first point in the installaion where I might have needed to edit a Linux file (rather than a Windows file.) Fortunately, I remembered that the editor named "nano" is always available on a gentoo minimal system, so in the colinux comsole I issued the command "nano net" to begin editing the file.

DNS Nameservers[]

It may be necessary to add some or all of the following dns servers:

colinux:/etc#nano resolv.conf
nameserver <ip.address.of.home.router>
nameserver <ip.address.of.isp>
nameserver <ip.address.of.another.isp>

To find the dns servers you should add, run the following command on the Hosting OS and look for the "DNS Servers" field:

ipconfig /all

Reconfigure Network Interface On the Fly[]

  ifconfig eth0 netmask broadcast
  route add default gw
  echo "nameserver" > /etc/resolv.conf

These changes take effect immediately. No need to reboot or restart networking. This should work with all images (Debian, Gentoo and Fedora).

To store the address permanently for your next boot, you should change your network configuration scripts. They are typicaly under /etc/networks, but they are differently for distributions.

Restarting a Network Interface[]

Reboot coLinux, or if you don't want to reboot, you can issue a command like this:


ifdown eth0
ifup eth0


/etc/init.d/networking restart


# /etc/init.d/net.eth0 restart

Manipulating IP Routes[]

This is related to Network#After starting coLinux, HostOS connection seems to go down, but happens in the Hosting OS instead of in the Hosting OS.

When there are two network cards configured in coLinux, it is sometimes necessary to manually adjust the routing tables. For example, eth0 has IP address and is the gateway for the network name servers (DNS), eth1 has IP address Suddenly, no url's can resolve. Look at the routing tables:

route -n

Find the culprit and remove it:

route del -net gw

To make this permanent:

echo "del -net gw" >> /etc/rc.local

Internet Connection Sharing (ICS)[]

Scenario: You have two computers, but only one of them has a connection to the Internet.

Description 1[]


  • Start -> My Network Places -> Properties"
  • "Set up a home or small office network" (link in the left-hand navigation bar)
  • "Next"
  • "Next"
  • "Set a connection method": "This computer connects directly to the Internet"
  • "Next"
  • "Select your Internet connection": Select the interface that moves packets out to the Internet
  • "Next"
  • "Select your private connection": Select the TAP virtual adapter. You may be able to bridge it with other interfaces, but I

didn't try that, and so I can't recommend it.

  • "Next"
  • "Give this computer a description and a name": Accept default values or change as desired
  • "Next"
  • "Name your network": I chose "DOMAIN", but I don't think it matters.
  • "Next".
  • "File and Printer sharing": "Turn off file and printer sharing" (just to be safe)
  • "Next"
  • "Ready to apply network settings": Very settings.
  • "Next"
  • "Please wait"
  • "You're almost done": Since the internal network with the TAP on it isn't going to host other Windows systems

(unless you've bridged it with a physical network so your XP system can route for hosts on that too) you don't need to install any drivers, so select "Just finish the wizard"

  • "Next"
  • "Completing the Network Setup Wizard": Follow the documentation links if you are interested, then click "Finish".

Description 2[]

On Windows XP:

Control Panel -> Network Connections -> Select the network adapter for sharing
-> Properties -> Tab Advanced -> Allow other network users...
-> Fill in name of the Home networking connection (the TAP-Win32 Adapter)
-> TAP-Win32 Adapter -> Ok.

Internet Connection Sharing will only work with being the IP address of the Tap device! Make sure that you do not assign a Gateway in the TAP IP settings (As shown above).

On Windows 2000:

Control Panel -> Network and Dial-UP Connections
-> Select the network adapter for sharing -> Properties -> Tab Sharing
-> Enable Internet Connection Sharing
-> Fill in name of the Home network (the TAP-Win32 Adapter)
-> TAP-Win32 Adapter -> Ok.
  • There must be at least two _active_ connections on Window2000 before ICS can be enabled.
  • If the NIC and TAP-Win32 are the only network adapters on the machine, coLinux will have to be started so that the "cable is connected" to the TAP-Win32 adapter, making it active.
  • Then, ICS may be enabled on the NIC.
  • Also, unless there are more than two adapters on the machine, there will be no place to enter the name of the Home network. Window2000 will assume that TAP-Win32 should be used.

For AOL Dial-up[]

I am using coLinux 0.8.0 with Debian-3.0r2.ext3-mit-backports.1gb.bz2 and all new modules.

Try this:
Edit coLinux configuration file and make sure you have this line:


Start coLinux.

Type nano /etc/network/interface and make sure you have a section like this:

auto eth0
iface eth0 inet static

Type nano /etc/resolv.conf and then set the DNS for Slirp:


Don't expect "ping google" to work since Slirp has no ping support.

You can now type "apt-get update" and it will work.

IP Address of the TAP Virtual Adapter[]

When Windows sets up ICS, it chooses a private address for the TAP virtual adapter. The address is in the 192.168.0.x range:


  ip address:
  network mask:
  (also written as

Home routers are often configured by default to assign addresses on this same (192.168.0.x), which will conflict with the DHCP server Windows set up for ICS.


Right-click on the TAP interface, select "Properties", double-click on the TCP/IP protocol and change the address!

You should choose an address in one of the private IP address spaces reserved in RFC 1918, which are

     10.x.x.x, that is, from to (10/8 prefix)
     172.16-31.x.x, that, from to  (172.16/12 prefix)
     192.168.x.x, that is, from to (192.168/16 prefix)


LanSuite Instead of ICS[]

  • While there are many features the ONE necessary to setup is the NAT
  • In the NAT setup dialogue connect the colinux TAP connection to your LAN internet connection.
  • Once it is setup you must start the program--which is basically a console log of all the activity.
  • To verify it is working try using apt-get or emerge on 'more' or some other small program and you should see 'establishing connection' and then the number of bytes transferred.
  • requires admin privileges.



   +-----------+            +------------+            . . . . . .
   |           |            |            |           .           .
   |  coLinux  | <--------> | Hosting OS | <-------> . Internet  .
   |    OS     |   TAP      |  bridged   |    Net    .           .
   |           |   or       |            |           .           .
   +-----------+   WinPcap  +------------+            . . . . . .
                     ,-----> C
  A <-----> B <----->*<----> D
                     `-----> E

Lets Explain what network bridging is:

  • Lets say you have computers A, B, C, D, E.
  • B has an ethernet card that connects to A and another that connects to a hub which splits off into computers C, D, E.
  • If you bridge the two ethernet cards on computer B, you would set all the IP settings on computers C, D, E to those necessary to be running directly off computer A.
  • That is because when you bridge the connections on the two B ethernet cards it is like computers B, C, D, E are all connected directly to A.
  • In the case A might is a router/gateway, you would set the settings in the A side of B and C, D, E to what is neccessary to route throught that router.

In Windows XP, you can either use WinPCAP or the builtin bridged network support. ( <max> If you use wireless: It seems that for many wireless routers, native windows bridging does not work, as the router won't accept packets with a different MAC-address)


Dynamic Host Configuration Protocol - allows a computer to receive an ip address from an address server. Most ADSL/DialUp users (and many cable users) already use some form of DHCP when they connect to the Internet, receiving a dynamic IP address from their ISP server. Usually, though, an ISP will only grant one dynamic address, meaning that coLinux will be refused when it requests an IP address. In addition, configuring a DHCP client often means knowing certain parameters to pass to the DHCP server, and making sure that the client and the server are speaking the same dialect of the DHCP protocol.

IP addresses and Network Masks[]

Every computer in a network needs to have its own IP address. They can be dynamicaly assigned by your ISP (or your modem/router, if you have one), dynamicaly assigned by windows (usually something like 169.254.xx.xx) or fixed IP addresses (configured by you or your system administrator, if you have one).

For two computers to communicate with each other in a local network, they need to have the same network address, that is, belong to the same network group. To connect to others IP addresses outside yout local network those packets need to be routed (more about this later).

Any one knows what an IP address is (at least an IPv4 address). Something like is an IPv4 address (IP version 4). The network address can be represented in different ways, but the usual way is by means of a network mask, that is something like Other ways include (notice the last 0) and (the first 24 bits define the network address).

You can see what IP addresses the windows machine is "known" by opening a command prompt window and running "ipconfig /all".

Windows IP Configuration

        Host Name . . . . . . . . . . . . : cowiki
        Primary Dns Suffix  . . . . . . . :
        Node Type . . . . . . . . . . . . : Hybrid
        IP Routing Enabled. . . . . . . . : No
        WINS Proxy Enabled. . . . . . . . : No
        DNS Suffix Search List. . . . . . : home

Ethernet adapter Local Area Connection:

        Connection-specific DNS Suffix  . : home
        Description . . . . . . . . . . . : DAVICOM 9102-Based PCI Fast Ethernet Adapter
        Physical Address. . . . . . . . . : 00-E0-4B-00-05-C9
        Dhcp Enabled. . . . . . . . . . . : Yes
        Autoconfiguration Enabled . . . . : Yes
        IP Address. . . . . . . . . . . . :
        Subnet Mask . . . . . . . . . . . :
        Default Gateway . . . . . . . . . :
        DHCP Server . . . . . . . . . . . :
        DNS Servers . . . . . . . . . . . :
        Lease Obtained. . . . . . . . . . : Wednesday, March 16, 2005 2:13:15 PM
        Lease Expires . . . . . . . . . . : Saturday, March 26, 2005 2:13:15 PM

Ethernet adapter Local Area Connection 2:

        Connection-specific DNS Suffix  . :
        Description . . . . . . . . . . . : TAP-Win32 Adapter V8 (coLinux)
        Physical Address. . . . . . . . . : 00-FF-DF-61-68-ED
        Dhcp Enabled. . . . . . . . . . . : No
        IP Address. . . . . . . . . . . . :
        Subnet Mask . . . . . . . . . . . :
        Default Gateway . . . . . . . . . :

As can be seen from the image, i have my network card with a fixed IP address, a network mask of (meaning I am in the network), my gateway is at (my ADSL router) and with a DNS server at (a linux machine serving as a DNS proxy, so that it can resolve local machine addresses).


Network Address Translation is the electronic equivalent of a (physical, as in snail) mail forwarding service. Everyone knows your public mailing address, but only the mail forwarder knows your true address. NAT is what happens when a home router (that Linksys box under your desk) gets an IP address from your ISP, but then gives each of your home computers a private IP address. Internet Connection Sharing (ICS) for Microsoft Windows does this. With ICS, Windows listens for address requests and responds by offering a private address to the requestor. If you have a router and have ICS enabled, then your communications are being forwarded twice.

An address is private if it begins with one of these three prefixes ("x" is where you put your own numbers):

  • 10.x.x.x
  • 172.16.x.x - 172.31.x.x
  • 192.168.x.x

See also

There are several ways to get Windows or a home router to forward network traffic to a coLinux OS.

   +-----------+           +-----------+            . . . . . .
   |           |           |           |           .           .
   |  coLinux  | <-------> |  Hosting  | <-------> . Internet  .
   |    OS     |    TAP    |    OS     |    Net    .           .
   |           |           |   (NAT)   |           .           .
   +-----------+           +-----------+            . . . . . .



A software firewall like ZoneAlarm may impede performance, which will be particularly noticeable when running X applications. It might be useful to set up a private network for coLinux and the windows Host, and configure any firewall applications not to monitor that network.

process priority[]

<UserTobias> I noticed a dramatic speedup (this is a tragedy, didn't see any speed difference) after giving the two processes "colinux-net-daemon" and "colinux-bridged" a priority "higher than normal" (using the Win2000 Taskmanager)

You also have to have permissions to be able to do this. If running coLinux as a service I don't know how to change priority.

With "Process Explorer" (Freeware) from Sysinternals the priority of a service can be changed.

The priority of both those daemons matters. The speed increase for me was ~130kb/sec to 4000+kb/sec - nice :)


It is often beneficial to restart Windows after changing network settings.

No response when coLinux OS pings Hosting OS[]

TCP/IP Checksums[]

If networking works, except between coLinux OS & Hosting OS

<nihilist> There have been a few instances where users have fully functional networking, but the a Hosting OS and coLinux OS cannot see each other.
For example, from a DOS prompt in 2k/XP, you cannot ping your coLinux instance. This is NOT a problem with coLinux, rather it has to do with the Windows network drivers.
If you right-click on your network connection, and click properties, it will bring up a dialog. At the top of this box it will say "Connect using:" Click on the configure button below the specific NIC. Click on the advanced tab, and there should be one (for Broadcom NICs), or many (Intel Pro/1000 NICs) options that deal with TCP/IP checksums. Ensure that all of these are set to none/no/off. Click okay till all of the dialogs are closed, and then you should be able to ping 2k/XP from co Linux, or coLinux from 2k/XP.

== Ping works, but other programs like ssh or browsers don't work between Hosting OS and coLinux OS ==

  • TCP/IP Checksums. Check the advanced properties on your NIC, it probably has something about TCP/IP Checksums, set that to none, or play with those settings until it works.
  • Some NIC drivers do not provide UI for changing this setting (e.g. Windows 2000 Intel(R) PRO/1000 MT driver). In this case the setting can be found and changed directly in registry with regedit. For the Intel PRO driver these are keys ChecksumTxTcp, ChecksumRxTcp, Checksum Tx Ip, ChecksumRxIp. The checksums are disabled when the keys are set to 0 and the computer is rebooted.

<John> In my experience I have had to change the IP number of the colinux to get things to work. I am using coLinux 0.6.1 and Fedora Core 1 with TAP network. I have been using Internet connection sharing but it only works one way.

  • I decided to try out the XP bridge instead. This is a bit tricky as when it is set up it wipes out settings which have to be restored. I created the bridge with only the outside network connected.
  • I set up the Colinux connection as usual with and its Tap connection as NOT connected to the bridge. In this state I can ping from colinux to
  • When I connect this to the bridge the settings of the second adapter disappear on Windows XP and the ethernet link goes dead.
  • What needs to be done is to reconfigure eth0 with an IP number as if it belonged to the outside network. In my case the network is 192.168.123.x so I chose
  • On Fedora core 1 this is ifconfig eth0 up.
  • Then it all works. On both the host computer (XP) and another one (WIndows 95 OSR2) I can see the Samba service and the VNC's and it looks as if coLinux is a member of the Windows workgroup.
  • This depends, of course, on having a spare IP address on the outside network. That may not always be so easy...

<asedeno> I've found that only Transmission Checksum offloading needs to be disabled (both TCP and IP), the Receive checksum offloading is ok. YMMV.

<piyo, 2004-07-18T01:06:23+0900> I confirmed asedeno's assertion. Using Windows XP, my Network Connection is "Intel(R) PRO/1000 CT", and in the Advanced Tab, I set the following settings:

  • Offload Receive IP Checksum: On (default: On)
  • Offload Receive TCP Checksum: On (default: On)
  • Offload Transmit IP Checksum: *Off* (default: On)
  • Offload Transmit TCP Checksum: *Off* (default: On)

Also make sure to "poweroff" and restart your Colinux session(s) if you make this change while they are running.

<DrRamble, 02022005> Similarly with the Intel PRO/100 built in to my Viglen (popular in UK academic institutions) PC. The advanced setting to disable is "Offload TCP Fragmentation". Again, don't forget to restart coLinux.

<CCrome, 2004-09-07> My 'Cisco Systems352 series Wireless LAN Adapter' does not work at all -- linux and host can't see each other.
Once I got out of my Lazy-Boy and walked over where I could plug in a land line, I switched adapters my 'Intel(R) PRO/100 VE' and everything worked perfectly.

<BrendanSimon, 2006-01-04>
If your NDIS driver does not have the settings available to disable tcp checksum offloading, then you can disable it by editing the registry as follows (I found this information at

  1. Click Start, click Run, type regedit, and then click OK.
  2. Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
  3. Click Edit, point to New, and then click DWORD Value.
  4. Type DisableTaskOffload as the entry name, and then press ENTER.
  5. Right-click DisableTaskOffload, and then click Modify.
  6. In the Value data box, type a value of 1, and then click OK.
  7. Quit Registry Editor.
  8. Restart your computer (Note: in my case it was enough to rightclick-deactivate and then rightclick-activate the interface-icon in networking. I don't love unnecessary windows restarts. - hth, TomS)

Bridged means on the same network[]

Upon reflection, it's obvious, but since I got bitten by this, it's probably worth noting: The IP addresses in the bridging description are examples - the actual IP address, gateway and netmask defined in /etc/network/interfaces should be on the same network as the NIC adaptor you want to bridge to, as reported by ipconfig on the Hosting OS.

For example, if, on Windows, ipconfig returns

Windows 2000 IP Configuration

Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . : ~WinProxy
IP Address. . . . . . . . . . . . :
Subnet Mask . . . . . . . . . . . :
Default Gateway . . . . . . . . . :

Then, on coLinux, /etc/network/interfaces should contain, e.g.

auto lo eth0

iface eth0 inet static

iface lo inet loopback

NOTE: when configuring the addresses on Windows XP you must set the properties on the bride and not on the individual connections. I has problems with this mistake. I was unable to connect to the internet and I couldn't see the linux machine either.

DHCP problems / duplicate address[]

If you see the following message: eth0: duplicate address detected! The IP address from the DHCP server will change every time coLinux start, and might take a long time to obtain the address. The workaround is to use a static IP address. Cause: ?

I noticed that the MAC address was different each time I restarted coLinux. By setting the MAC address to that expected by the DHCP server the problem was solved.

In the colinux.xml configuration file, find the network configuration line and append mac="xx:xx:xx:xx:xx:xx", inserting the MAC address for the virtual eth0 card.

My colinux.xml looks like :

<network index="0" type="bridged" name="Local Area Connection" mac="xx:xx:xx:xx:xx:xx" />

or, for a .bat file:

eth0=pcap-bridge,"Local Area Connection",xx:xx:xx:xx:xx:xx

<ionreflex> is this really a bug/problem ? i have specified a MAC in my config file so it doesn't change, and my DHCP reservation works like a charm; i do get the "duplicate address" message, thought it only meant that coLinux detect the Windoz address, and i don't have any problems...

After starting coLinux, HostOS connection seems to go down[]

After I start coLinux using this command:

colinux-daemon kernel=vmlinux cobd0=Debian-20040605-mit.ext3.1610mb cobd1=swap_device mem=512 eth0=tuntap,"coLinux",, root=/dev/cobd0

The network connection on the Host OS doesn't seem to respond. It remains connected but no ping.

Solution: When the coLinux guest boots up, Windows automatically adds another route. In the example below, the route with metric 30 was automatically added. This is a spurious gateway, as the only two computers on the 192.168.5.x network are the Hosting OS and the coLinux Guest. It should be deleted with the command "route delete"

C:\>route print
Interface List
0x1 ........................... MS TCP Loopback interface
0x3 ...00 0e 31 66 4a a2 ...... Intel(R) PRO/Wireless 2915ABG Network Connection
 - Packet Scheduler Miniport
0x4 ...00 ff 3d 2a 1c b3 ...... TAP-Win32 Adapter V8 (coLinux) - Packet Schedule
r Miniport
0x20002 ...00 10 9e ac 13 b4 ...... Broadcom NetXtreme Gigabit Ethernet - Packet
 Scheduler Miniport
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
[remaining output deleted]
C:\>route delete

It may even be necessary to add a default route to your gateway (replace with your gateway IP address)

route add MASK

A permanent solution: In the advanced TCP/IP settings uncheck "automatic metric" and set the value to something higher than your "normal" route. In the case above you would set to something larger than 40.

Keep Windows off the network -- surf via Linux[]

More than half the Windows users have Spyware on their computers which they will never be able to remove completely from their system (except for erasing all data and reinstalling their system from scratch), even by using a whole Armada of anti-spyware and antivirus programs like AdAware, Spy Sweeper, Spybot Search & Destroy, Antivirus, Norton Antivirus etc. Moreover, there's the ever-increasing Microsoft espionage built into the system -- let alone Windows Vista.

coLinux is a solution to this problem, if you can't do without Windows programs. This setup keeps Windows off the network and allows it to see only the virtual Linux machine. Linux, on the other hand, has access to all protocols of the internet and, in addition, sees the Windows host:

   | Hosting OS |           
   | Windows    |  invalid conn.  +------------+           . . . . . .
   |            +<xxxxxxxxxxxxxxx>+            |          .          .
   +--+---------+                 |  WinPcap   |          . LAN      .
      |TAP virtual cable (eth1)   |  Virtual   +<-------->+ or       .
   +--+---------+                 |  Bridge    | physical . Internet .
   |            +<--------------->+            | cable     . . . . . .
   |            |  WinPcap        +------------+
   | coLinux OS |  virtual cable
   |            |  (eth0)
  • If you configured any coLinux ethernet network services to start up during booting, change this temporarily, e.g. by "ONBOOT=no" in /etc/sysconfig/network-scripts/ifcfg-eth* for Fedora.
  • Shut down coLinux by "/sbin/shutdown -h now".
  • Windows: Control Panel -> Network Connections: Choose your original physical Windows connection to the internet and rename it to something meaningful, e.g. physical_adapter. Right click on it -> Properties -> TCP/IP -> Properties and set the IP and subnet mask to a fixed value not accepted by your DHCP provider, e.g. and, respectively. Don't use connection sharing in Right click -> Properties -> Advanced.
  • Control Panel -> Network Connections: Choose your Tap-Win32 Adapter and rename it to Colinux. Right click on it -> Properties -> TCP/IP -> Properties and set the IP to a fixed value and the subnet mask to Leave the gateway blank. Don't use connection sharing here either. I choose 192.168.1.* here instead of 192.168.0.* in order to avoid conflicts with local area networks using the latter IP space.
  • The XML config file (or analogously the command line parameter list) of your colinux startup receives the following network parameters:
<network index="0" type="bridged" name="<xxx>" />
<network index="1" type="tap" name="<xxx>"  />

or, for a .bat file

eth0=pcap-bridge,"<xxx>" ^

where <xxx>, which is case sensitive, is replaced by the name of the connection in "Network Connections"

  • Now start up again your coLinux installation and set the following parameters for the two virtual Linux network adapters. (This is for Fedora. The others have similar config files with the same parameters.)
cd /etc/sysconfig/network-scripts
cat <<EOF > $MOUNTPOINT/etc/sysconfig/network-scripts/ifcfg-eth0
cat <<EOF > $MOUNTPOINT/etc/sysconfig/network-scripts/ifcfg-eth1
eth0 uses the bridge to the physical network adapter to connect to the internet. By
ifup eth0
it receives a DHCP address from your provider. This even works for providers who grant you only one IP address. You can now test the connection by
Now you can start up eth1:
ifup eth1
which will be used to talk to the Windows host, e.g. to its X server.
Test again:
ping        # eth1-IP of the Windows box
Test also from windows:
ping        # eth1-IP of the Linux box
ping  # This will print an error message.
  • Here's the configuration of the Cygwin X server using the eth1 connection. Edit c:/path-to-cygwin/usr/X11R6/bin/startxdmcp.bat (the second line has been commented out and is replaced by the third line):
rem %RUN% XWin -query %REMOTE_HOST% -nodecoration -lesspointer 
run XWin_GL -query %REMOTE_HOST% -nodecoration -clipboard -lesspointer -rootless -ac
In your coLinux box, edit /etc/gdm/custom.conf:
In /usr/share/gdm/defaults.conf remove the line
and start gdm.
Now start Cygwin's startxdmcp.bat and you'll see the gdm welcome window. After logging in, you can start firefox in your coLinux box to browse the web and start Thunderbird to read your mails while Windows is ignorant of any other computer in the world except for, which is your Linux box. Voilà! --Brunod 05:41, 6 January 2007 (UTC)

In case you absolutely need to have http access from Windows, e.g. for downloading program installers, you can use an http proxy on your Linux box:

  • Install privoxy
  • Edit /etc/privoxy/config (you can add further security-related configurations)
# Find the following lines and comment them out, as shown:
#debug 1
# Set port to the standard 3128 
# (a matter of taste, you could also keep the privoxy default, 8118)
# Permit Windows to access privoxy
  • Add the following line to /etc/host.conf, if not already present:
multi on
  • Add the following line to /etc/hosts myhost
  • Start privoxy:
cd /etc/privoxy

--Brunod 14:31, 13 January 2007 (UTC)

Miscellaneous suggestions[]

  • could someone please explain why a bridged connection has only one IP? If a bridged connection is search for its IP, which interface is used for the DHCP request? My bridge simply has no address...
  • How about explaining a bit more background for this important step? Like explainin that the TAP and eth0 is not the same thing, but rather both need an address and are connected with a virtual wire.
  • Bridging makes a "virtual hub" between the various interfaces involved. A bridged connection only has one IP, because that bridged adapter interface that appears when you bridge multiple interfaces becomes the Windows' virtual interface. It is therefore Windows' port into the virtual hub, and therefore has only 1 IP.

Adding the loopback device in coLinux[]

We recommend to add the loopback interface which permit the coLinux to access itself via localhost or : a lot of applications will feel better with this interface configured, as XWindow forwarding.

For debian, add this in /etc/network/interfaces :

iface lo inet loopback

And this in /etc/hosts (note: if the /etc/hosts file does not exist, create it) : localhost.localdomain localhost

<Gniarf> It may be useful to also add this line : colinux.colinuxdomain colinux

where colinux is your /etc/hostname, since I had a few debian configuration applications complaining about that. not sure about that, we dont want to install bind yet, do we ?

<melling> VNC did not work properly without setting my /etc/hosts. Play it safe and add the loopback device and set your /etc/hosts.

Preventing "network cable unplugged" message[]

If you use coLinux w/ WinXP and TAP-Win32 in a manner in which you are frequently restarting the daemon, you might be annoyed by the "network cable unplugged" message. You can get rid of it with the following:

Control-Panel -> Network Connections
 -> right click on the TAP-Win32 connection
 -> Properties -> Configure -> Advanced -> Media Status = Always connected.

At least for the debian image, this might also greatly shorten your boot time.

This also fixed my network problem where I could not ping coLinux from my windows machine. Changing the above setting fixed not only my ping problem but allowed my windows vnc viewer to connect to coLinux's vnc server.

Lost & Return connection[]

If the host connection is lost coNet will disable but will not automatically return if re-start, so you need to enable coNet manually.

Example (bridged):

colinux-bridged-net-daemon.exe -i 0 -mac 00:4A:41:52:45:4B -n Intel

Other Wiki Related Pages[]

Using a proxy server[]

It is possible to use a proxy server instead of "Internet Connection Sharing" if you just want to have access to the usual Internet applications (HTTP, FTP, ...) without having to reconfigure your normal Internet connection. It is also possible to access services running under coLinux with ProProxy. I got the Gentoo image to work with hhproxy and even "emerge sync" works with rsync throught the HTTP proxy.

Just follow the instructions to configure hhproxy with 2 ethernet cards and inside coLinux set the correct http_proxy, ftp_proxy and RSYNC_PROXY environment variables to use hhproxy on the TAP-Win32 IP.

FreeProxy is also a good proxy server to use with coLinux, and it's *significantly easier* to set up than hhproxy. See Using FreeProxy with CoLinux

Here's a howto on getting colinux running on a Win2k laptop with wireless networking when you can't use Microsoft's Internet Connection Sharing. My directions are with hhProxy but can probably be adapted for use with FreeProxy although I haven't tried it yet.

(By the way, these instructions worked fine for me with the coLinux-20040620 snapshot -- MedioVia)

ProProxy is great for redirecting ports from your Hosting OS to the colinux kernel. This config file redirects port 22(ssh) to colinux, so ssh/putty WINDOWS-IP will redirect you directly into colinux.


Use port 80 instead of 22 if you want to run a webserver inside colinux.
Proproxy can be started multiple times with different configfiles.

Connection trapping[]

This provides an alternative method where using ICS is impossible or impractical
(public wlans on the range spring to mind).

Note: : This requires the following setting enabled in your kernel

CONFIG_IP_NF_NAT_LOCAL: Enable this if you need to use dnat on connections orginating from local process on the nat box itself. coLinux 0.6.2 and newer already have this setting enabled and so you shouldn't need to do anything special to your kernel or modules, just extract the vmlinux-modules.tar.gz into your filesystem (on /, which will put the files in /lib/modules/<kernel_version>).

Note for Debian Sarge:

If you are running Sarge, (_iirc (Who is "I"?)_, Woody is not affected cant test atm other ditros may be), you must do a recursive chown of the extracted modules to root or it won't work.

_I (Who is "I"?)_ have uploaded the code to

The version 0.01 was built with freepascal 1.9.2 which seems to have stopped udp in it from working right now it requires an existing network connection but i plan to replace that with coserial as soon as its available.

Note: : You must have a default gateway set even if it is nonsense ;). This can be achived with no adaptor availible by putting a static ip on lo:0 and adding a default gateway on it.

Note: : You must have the loopback adaptor set up properly.

First, you must edit setupnat change to the netblock of the lan linking host and coLinux OS. Then,

  • run connector.exe on the host
  • run ./setupnat on the colinux system
  • run ./accepter hostip & on the colinux system

For DNS, you must either set a suitable DNS server in /etc/resolv.conf or if you are roaming between networks and don't want to keep editing /etc/resolv.conf, you can run bind on coLinux and point /etc/resolv.conf to

Windows 2000 Asterisk BRIDGED config behind a Linksys router connected to the Internet[]

  • Run the asterisk for windows installer
  • In edit the astwind.colinux.xml file (make sure you arent editing the similar file - default.colinux.xml)

You should have the following line:

<network index='0' name='574' type='bridged'/>
  • Contrary to other's instructions, the "name" above is NOT the name you gave to your LAN connection, it is also NOT the name found under Properties-->"Connect using:"
  • You can find the NIC adapter name that coLinux is looking for by watching the colinux boot window (you see this when you run astwind.bat) in the lines that begin with "bridged-net-daemon"... once you have found the name, you may type only a substring of it in the "name" field.
  • In /etc/network/interfaces
Use DHCP if you have it enabled on your linksys box. Or, if you use a static IP, make sure you choose an unused address from the same subnet on which your windows box resides and use the ip address of the linksys as your gateway.
  • In /etc/resolv.conf define the address of your ISPs DNS servers.
  • Start astwind.cmd by double clicking (or running it from the command line).
  • coLinux will now have a unique IP address and MAC address on the same subnet as your Windows2000 machine and your Linksys box (inside subnet).
If you used DHCP, you can see the address with ifconfig command.
  • The TAP adapter will appear to be disconnected at all times, if this bothers you, go to its properties->click the "configure" button-> advanced tab -> and set the "media status" to always connected.
  • The IP address assigned to the TAP adapter seems to be irrelevant in bridged mode.
I used one time and the next time.

Accessing windows based VPN[]

Consider this setup. You have a Wifi card connecting to internet. After that, you setup VPN connection on windows to your workplace. You want linux to access the VPN too.

The following configuration works: slirp as the main device (eth0), and tap as local communication between colinux and windows (eth1).

Note: no Internet-Connection-Sharing (ICS) is used in this setup.

Text based config:

eth1=tuntap,"Local Area Connection 2"

old XML config:

<network index="0" type="slirp" />
<network index="1" name="Local Area Connection 2" type="tap"/>

Then, configure eth0 to use DHCP, and eth1 to pick a local address to communicate with windows. For my setup, eth1 is set to, and the corresponding windows tap device "Local Area Connection 2" is set to, as per docs above. The slirp issues DHCP address to eth0, and installs default route. Use this default route, cause otherwise it will not work.

VPN (CheckPoint VPN-1 SecureClient)[]

If you use a VPN connection to connect to fx. your workplace, the following should enable you to access internet from coLinux. It is tested with CheckPoint VPN-1 SecureClient.

First, in your settings.txt, enable slirp as eth0 adapter and tuntap as eth1:


Then setup the VPN connection to your workplace and go to command prompt to find the IP address of your DNS:

ipconfig /all

The address(es) of the DNS server(s) will appear under the adapter name of your VPN client (in the case of VPN-1: "Check Point Virtual Network Adapter For SecureClient - SecuRemote Miniport").

In coLinux, insert the DNS addresses into /etc/resolv.conf, so that it reads something like:

nameserver x.x.x.x
nameserver y.y.y.y

Finally, restart coLinux and try the connection with fx.


VPN and VNC[]

If you are using VNC and at the same time using a VPN connection to connect to fx. your workplace, you'll propably find out that the VPN prevents you from connecting to VNC. The following should enable you to access VNC even though a VPN is running. It is tested with CheckPoint VPN-1 SecureClient and realVNC.

First, edit the line eth0=slirp in settings.txt to


where 5901 is the port of realVNC. Adjust this value to your needs.

Now restart andLinux, start your VNC-server in coLinux and connect the client to This should successfully start a VNC session.

When you are not connected to the VPN you may still connect the VNC client to (or whatever address you used before).

Move to a Different Article[]

This is _too_ obvious, but

Use FTPD to transfer files with Windows[]

You know, the wiki says cofs is buggy, why not use ftp? I installed it by "apt-get install ftpd" (in Debian) under colinux. Then in Windows, "ftp", and input userid and password. (I think "root" can't do this, so use a regular account. I had already set one up and forgot how.) This will allow you to transfer files to and from the colinux image. If you have a GUI ftp client for windows, then this may be as simple as drag-n-drop. This is for the TAP connection, not slirp.

Other Resources[]