[root@... root]# ip addr
1: lo: <LOOPBACK> mtu 16436 qdisc noop
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:43:4f:4e:45:30 brd ff:ff:ff:ff:ff:ff
inet 192.168.19.1/24 brd 192.168.19.255 scope global eth0:0
inet 192.168.20.3/24 brd 192.168.20.255 scope global eth0
[root@... root]# ip route
192.168.20.0/24 dev eth0 proto kernel scope link src 192.168.20.3
192.168.19.0/24 dev eth0 proto kernel scope link src 192.168.19.1
default via 192.168.20.1 dev eth0
(note that to /really/ do this properly, I need coLinux to have 2 bridge
and/or tap nics. Right now I can only get one eth to work under coLinux.
I assume this is a implementation issue, however, I have not looked at the
[root@... root]# iptables -L POSTROUTING -n -t nat
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
SNAT all -- 192.168.19.0/24 0.0.0.0/0 to:192.168.20.3
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.19.8
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.19.1
Pretend here that my outside world address is 192.168.20.3. I have
created a subnet which lives outside of my ISP's range of 192.168.19.0/24.
192.168.20.0/24 is my ISP's block.
coLinux bridges using PCAP eth0 with my Windows NIC.
My windows box routes through coLinux [192.168.19.1] where coLinux SNAT's
my 192.168.19.0/24 address as 192.168.20.3 [outside addr].
For all of those who might scan my external address [192.168.20.3], they
will see my coLinux box not my windows box.
If my isp brings up a host with an address of 192.168.19.99, 192.168.19.99
can see my windows box directly as 192.168.19.8 and /will not/ be
firewalled by coLinux. This current config does assume that your ISP is
not malicious /and/ that nobody source routes addresses to your box (or
your ISP blocks source routing and/or private nets).
1. I can debind TCP/IP from my windows interface and coLinux is still able
to reach the Internet because of the PCAP bridge.
2. Because we can debind our external nic, if coLinux can support multiple
TAP/bridge interfaces, we can create a true firewall out of coLinux. The
TAP device can then be used as the internal network interface and the
external interface can be bridged. Of course this can't be tested until
coLinux supports multiple nics. I am also thinking of throwing another
nic into my box and compiling a Linux kernel driver for it and disable it
in Windows to see if I can fake that into being used as eth1.
I've got a 768k/128k dsl connection and DSL speed test showed
~650kbit/131kbit which is acceptable. Because the coLinux network
interface is suboptimal, the latency does increase by about 15ms.
Fortunately, most people could care less about 15ms and the potential
advantage of using Linux's firewall flexibility within windows is immense.
Kudos to all who have put work into this project, I think it has great
potential and we are only starting to see the beginning of what this
really opens up. Now we just look forward to your creative minds and cool
twists that can be used in tying windows and Linux together and have one
rock-solid and extremely flexible desktop.
Your thoughts and/or ideas?
National Security Concepts, Inc.
PO Box 3567
Tualatin, OR 97062
Voice: (503) 293-7656
Fax: (503) 885-0770