Virtually There

Some time ago I decided to set up a qemu virtual machine (VM) with Windows 2000 (W2K). While just getting a basic VM running was pretty easy, getting my W2K installation updated with all of the various patches that have been released over the years was anything but easy. I described the process I went though in my article Virtual Hell.

Since getting my W2K VM running I decided to take a couple of classes on network security through a local community college. One of the classes is "Computer Security and Penetration Testing". It occurred to me that having my W2K VM be accessible on my network would be a great way to delve into some of the more interesting subjects from the penetration testing class like scanning, spoofing and hacking. The gotcha was I needed to set up my host system so that the NIC was bridged to the virtual NIC of the VM.

I did a little Googling and found a variety of articles on how to do this for various Linux distributions. After several unsuccessful attempts, I tried looking for a how-to for my distribution, CentOS, and found the CentOS wiki KVM how-to. After undoing several things I had done that may have worked for other distributions, I slowly hacked my way through setting up my KVM in bridging mode.

Obviously, if things had gone smoothly I wouldn't be bothering with a blog post to describe what I did. The steps given in the CentOS wiki how-to leave out a number of details that might be readily apparent to others but which weren't at all obvious to me.

First, don't trip over your own mistakes. That means checking to be sure that any remnants of a previous attempt are no longer present. For me, this came down to:

# Remove old bridge module

rmmod bridge

# Remove old tun module

rmmod tun

# Restart network

service network restart

These commands should put the network interface on the host back to the way it was before any attempts at getting bridging working.

What I also discovered was that the procedure given for setting up the bridge meant my host system disappeared from my network. I tried several combinations of DHCP and fixed IP addresses before finally coming up with giving my host workstation a fixed IP address and letting the VM get its address through DHCP. This almost made everything right but what else needs to be fixed makes more sense later. An additional benefit of the host system having a fixed IP address and the VM operating system being configured for DHCP is that the same VM can be used regardless of whether the VM is going to be brought up using the native NAT capability of VM or will be visible on the network using a bridge.

At this point the bridge can be built using the process documented on the CentOS wiki:

[root@bend ~]# brctl addbr br0

[root@bend ~]# ifconfig eth0 0.0.0.0

[root@bend ~]# brctl addif br0 eth0

[root@bend ~]# dhclient br0

dhclient(21466) is already running - exiting.

...(lots more spewage from dhclient)...


If dhclient is still/already running at this point, it needs to be killed:

[root@bend ~]# ps aux | grep dhclient

root 21466 0.0 0.0 6724 812 ? Ss 09:01 0:00 dhclient br0

root 24937 0.0 0.0 61120 752 pts/1 R+ 10:42 0:00 grep dhclient

[root@bend ~]# kill 21466

[root@bend ~]# dhclient br0

Internet Systems Consortium DHCP Client V3.0.5-RedHat

Copyright 2004-2006 Internet Systems Consortium.

All rights reserved.

For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/br0/00:0a:5e:1a:ee:4b

Sending on LPF/br0/00:0a:5e:1a:ee:4b

Sending on Socket/fallback

DHCPREQUEST on br0 to 255.255.255.255 port 67

DHCPREQUEST on br0 to 255.255.255.255 port 67

DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 8

DHCPDISCOVER on br0 to 255.255.255.255 port 67 interval 10

DHCPOFFER from 192.168.0.1

DHCPREQUEST on br0 to 255.255.255.255 port 67

DHCPACK from 192.168.0.1

bound to 192.168.0.192 -- renewal in 8889 seconds.

[root@bend ~]# modprobe tun

[root@bend ~]# tunctl -b -u dave

tap0

[root@bend ~]# ifconfig tap0 up

[root@bend ~]# brctl addif br0 tap0

This is where the CentOS wiki article stops. At this point the VM can be brought up and it will be visible to the rest of the network. There's just a small gotcha and that is the host is no longer visible and any network sessions (e.g., ssh sessions) to other systems on the network are suspended. The solution to this problem is to just use ifconfig to give the host NIC back its IP address:

ifconfig eth0 192.168.0.2

That's it. The VM can not only see out but also be seen. The host system continues to function with full capabilities. The only complaint I have is I have to use sudo to bring up the VM in bridging mode since a regular user program isn't allowed to access the underlying device for the tap interface (/dev/net/tun). This can be fixed by using chown to change the ownership of /dev/net/tun to the appropriate user

chown dave:dave /dev/net/tun

Once this is done the qemu VM can be brought up in user mode.

According to various articles for configuring bridging with tun/tap under other Linux distributions it should be possible to embed these commands in the start-up script for qemu. The CentOS wiki article complained that this didn't work for the author of that article so this will have to wait until I'm motivated to see if I can make that work.

Cheers,

Dave