Using coLinux As a Firewall[]

coLinux can be used as a firewall, but it has to be done in a very specific fashion, or else the firewall is going to be able to be circumvented.

Right now, none of this has been tested. I'm explaining this as a matter of theory, which should work. When I do have time, I will update these pages with better, properly tested notes.

With standard internet firewalls, there are two ways of doing it, and both ways can be emualted with coLinux. The first is having two NICs in a machine, one being "internal" and the other being "external". The external NIC takes care of all exterior communication to the Internet, while the internal deals with the internal network of the LAN. In order to bridge the communications between the LAN and the Internet, usually NAT is used, allowing systems on the inside to communicate out, while keeping any foreign traffic out by blocking ports. This is all well and good, but if an externally routeable network is used on the internal LAN portion, the ability to break into the internal network always exists, no matter how strong the filter or firewall is. For this reason, it is often better to use a non-routeable network on your internal network, to insure that noone can get into it.

In the world of coLinux, this type of network can be emulated with two bridged interfaces. One interface communicates with the "real world", while the other takes care of all LAN communications. All machines on the inside, including the coLinux host, use non-routeable IP addresses while the other bridge interface uses an Internet routeable IP address. This way, the colinux can act as a NAT box.

The other way to do this is to use 1 bridged network, and allow it to communicate on two networks. This is called "one-armed routing", where all traffic comes in and out of the same NIC. With this one bridged interface, two aliases can be used (this part hasn't been tested.. its quite possible that a bridged coLinux interface won't communicate well with aliasing) and traffic can be communicated on both networks, bridging by NAT.

Ian Bonnycastle --

There is a problem with this from a security point-of-view: Because coLinux uses the Windows TAP device to access the network hardware, every packet is STILL going to be processed by the Windows TCP/IP stack, so the system is still going to be vulnerable to weaknesses in the Windows networking code. Its a good way of adding routing / NAT / firewall capabilities to a windows box, but it's not going to be as secure as a native linux install.

Tom Martin --

Instructions (by Ian Bonnycastle, taken from coLinux-users List) The steps are as follows:

1. First make sure that you have a TAP driver installed on your Windows machne that coLinux can use. This is going to be the main communications point between coLinux and Windows.

2. Make sure you have winpcap installed.

3. Make sure that coLinux is configured to use both these interfaces. I would suggest using eth0 for the external interface (to the Internet) and eth1 for the internal interface (to Windows), but this is totally arbitrary.

4. On the TAP device, configure your network to whatever you like (I'm going to use in this example), so make sure that coLinux is .1 and Windows is .5 (for example).

5. In Windows, set your default route and your nameserver to (in this example). This will point your Windows box towards the Internet.

6. Set up your coLinux external interface as either DHCP (if your windows box is connected directly to your cable modem) or an IP on your network (if you have an internal network, or on a corporate LAN).

7. Set your winpcap interface to have the same MAC address as your external interface. (How to do this is in the Wiki). This is not so important for wired NIC cards, but EXTREMELY important for wireless ethernet cards (if you don't do this, you're going to have difficulty getting coLinux to talk to the wireless network).

8. Make sure (and this is extremely important too) you turn OFF TCP/IP on your external interface in Windows. Go into Network Properties, and click the TCP/IP checkbox. Do this ONLY on the external interface. This will probably also disable the "File and Print Sharing" protocol as well.

Since now your system is set up correctly, you should have the:

Windows <====> coLinux <====> Internet

setup you want. coLinux should have a default route to the Internet, and Windows should have no *direct* connection to the Internet anymore. You can also set up coLinux to do iptables firewalling (if you use kernel 2.6.x). This way, you should be able to properly protect your windows machine from the Internet. This way is also pretty elaborate, so if you already have a corporate firewall, or a router that does firewalling or NAT, using this method is usually too much overhead to make any sense. Its usually a good method for systems

  • directly* connected to the Internet. I've tested it, and it gets good

speed on my network.

  • NOTE: I just realized that you're going to have to set up NAT on your coLinux box with iptables to properly NAT all outbound connections from your Windows box. -- Ian

Note, however, that doing this is putting packets through the conet virtual network driver *twice*, and could have potential speed problems. I've never personally ran into them, but that doesn't mean they're not there. YMMV.

Comment by <SzaTam>, Hungary: It works for me, but it's really not that fast. Although it is enough for most home dsl/cable connections. Combined with netfilter, you can do anything a standalone router can. For bridging and qos you have to compile a custom kernel.

Comment by aderry, Hong Kong: I am using coLinux as a router on a 600 Mhz machine with two network interfaces. The setup is similar to what is described in this page except that I use two real interfaces. When both interfaces are bridged to co Linux using WinPCAP, the machine that host coLinux still have decent connection speed through the virtual router, but the speed of all other machines on local LAN is unacceptably slow. The problem disappeared when I changed the local LAN interface to native windows network bridging with a TAP interface. My subjective evaluation is that it performs as good as a standalone router.

MassTranslated on Sun Apr 23 17:36:59 UTC 2006