Monday, 15 June 2009

Clone an IPCop installation over the network

Perhaps you need to clone IPCop to replace the disk, make a working copy for another machine, alter the sizes of the partitions, or for some other reason. This can be done over the network with nothing more than ssh access to IPCop. Remember, clone means clone and you get all the settings and logs replicated, so you should deal with those once you have the clone working.

Connect up the destination disk to a spare machine and boot up with a Puppy Linux CD. There is no reason some other distro couldn't be used, it's just that Puppy Linux runs off the CD and allows you to connect up the disk as the normal primary disk. Another rescue distro would work equally well.

Assuming you have Puppy Linux up and running, first get a network connection with the Network Wizard. Then partition your disk. IPCop creates three partitions, the first for /boot, the second for /var/log and the third for /. The first has only to be about 8-10MB. The third should be about 200-500MB, and the second can use up all the remaining space. You can look at your current IPCop to see the usage of space and tweak these numbers. Use fdisk to do the partition. I will not give a fdisk tutorial here, you can use the built-in help or find its documentation. If your Linux kernel is 2.6 and addresses the disk as sda then substitute sda for hda in the following instructions. In what follows, # is the root shell prompt, which you don't type and // starts a comment, which you don't type either.

# fdisk /dev/hda
// create primary partitions 1, 2 and 4 with the required sizes
// change the type to Linux (0x83)
// (optional) set partition 1 to bootable

Now format the partitions ext3. A gotcha is that recent mke2fs programs set various features on the filesystems that are not supported by the e2fsck program in IPCop. You need to avoid them.

# mke2fs -j -O none,filetype,sparse_super /dev/hda1
# mke2fs -j -O none,filetype,sparse_super /dev/hda2
# mke2fs -j -O none,filetype,sparse_super /dev/hda4

Mount the partitions

# mkdir /ipcop
# mount /dev/hda4 /ipcop
# mkdir -p /ipcop/boot /ipcop/var/log
# mount /dev/hda1 /ipcop/boot
# mount /dev/hda2 /ipcop/var/log

Create a swapfile. The size should be 2x RAM on the destination machine but this is not critical.

# dd if=/dev/zero of=/ipcop/swapfile bs=1M count=64
// e.g. for a 64MB swapfile
# mkswap /ipcop/swapfile

Make some required directories.

# mkdir /ipcop/proc

Now copy the files over. It doesn't take very long, IPCop is a small distro. The backslashes indicate either type it all on one line or type the backslash to the shell to continue the line. You will see the filenames as they are extracted.

# cd /ipcop
# ssh -p 222 \
 'cd /; tar cf - --numeric-owner bin boot dev etc fastboot home lib mnt root sbin tmp usr var' | \
 tar xvf -

Now you need to install GRUB. grub> is the GRUB prompt.

# grub
grub> device (hd0) /dev/hda
grub> root (hd0,0)
grub> setup (hd0)
grub> quit

GRUB should display messages about installing various files. Now umount the IPCop disk.

# cd /
# umount /ipcop/var/log
# umount /ipcop/boot
# umount /ipcop

Now take out the Puppy Linux CD and reboot with the primary disk. For some reason, only the bootloader has been installed, not the menu, so for the first time you need to run GRUB manually. You might want to disconnect the network cable so that you don't interfere with the network in case IPCop starts using the network cards.

grub> root (hd0,0)
grub> kernel /vmlinuz... root=/dev/hda4
grub> boot

You can use tab file completion to fill out the vmlinuz kernel filename. Once booted into IPCop you need to run grub-install to fix the GRUB menu. BTW, inside IPCop you do not substitute sda for hda because IPCop runs Linux 2.4.

# grub-install --no-floppy /dev/hda

If you have no floppy, you might want to remove the line with fd0 in /boot/grub/ otherwise the probing will take a long time.

Now you can login to your new IPCop box and fix up the hardware details and the configuration.

Tuesday, 28 April 2009

Running a production IPCop in a Virtualbox


A friend of mine was running IPCop. He also wanted to have a Samba fileserver that would be available to store data. Not wanting two machines powered up all the time, he asked me if I could combine the two.

At first I said that I didn't think it was secure. I thought that perhaps he should run one of those combined firewall/server distros like Clarkconnect, Endian Firewall, etc. But IPCop has a nice web interface, and a small footprint.

When Virtualbox 1.6.2 came out, I decided to experiment to see if a production IPCop firewall could be run inside a Virtualbox VM on a minimal distribution such as Ubuntu or Debian server. I have since also repeated the experiment with VirtualBox 2.1.4, where host networking is much simpler. The sections that differ are noted as such.

Is this for me?

That depends. You would have to appreciate IPCop's flexibility to want to use it over an embedded router. Or perhaps you are disappointed in the throughput of the cheaper embedded routers, but don't want to go all the way with firewall/server distros like Clarkconnect, Endian Firewall and their ilk. This hack occupies a narrow niche, so outside of its boundaries, there may be no advantages to you.


I will describe the setup on an Ubuntu/Debian host. It will work with other Linux distros with the appropriate adjustments to the commands. I have not tried it under non-Linux OSes, so that is for you to experiment.

The minimum specs for the host are:
  • 500MHz CPU
  • 192MB RAM
  • 2 NICs
  • 2GB disk space for host OS and IPCop, any extra can be for data
I'd be interested your experiences with lower or higher specs.

First do a standard Ubuntu 8.04 server install. Note that I picked a CLI server configuration to minimise footprint. That's also the reason we don't use the Virtualbox GUI setup tools, but use VBoxHeadless and VRDP instead, so as not to require X11 libraries. I will not describe this install. Choose the services you want, e.g. LAMP, Samba, etc. Remember to do an apt-get update and apt-get upgrade to get the latest fixed packages for your install. In particular I believe there has been a kernel update which you should do before fetching the Virtualbox package. (BTW I will not mention the implicit sudo or su required to do root-only operations.)
Next install the Virtualbox software, either the OSE version from the Ubuntu repositories or the Sun .deb version. If you are using the Sun version you may need to run:

/etc/init.d/vboxdrv setup

to compile the driver for the kernel version you are using. You will need gcc and the kernel sources to do this.

Next add the sysv-rc-conf and dhcp3-server packages.

apt-get install sysv-rc-conf dhcp3-server

Setup for 1.6.2

First add the bridge-utils package.

apt-get install bridge-utils

Set up the two NICs like the "wiring diagram" below by editing /etc/network/interfaces. eth0 is the inside NIC which responds to both the host and IPCop's addresses. eth1 is the outside NIC which is only attached to IPCop's external address.

# The primary network interface
auto br0
iface br0 inet static
        bridge_ports eth0
        post-up chgrp vboxusers /dev/net/tun

# The secondary network interface
auto br1
iface br1 inet manual
        bridge_ports eth1
        post-up chgrp vboxusers /dev/net/tun

End of setup for 1.6.2.

Setup for 2.1.4

In 2.1.x, it is much simpler. You simply have to set up the host OS networking as normal, bind the guest virtual NICs to the host NICS and then configure the guest NICs as normal within the guest. So the /etc/network/interfaces files looks like this:

# The primary network interface
auto eth0
iface eth0 inet static

# The secondary network interface
auto eth1
iface eth1 inet manual

End of setup for 2.1.4.

In both cases the wiring diagram is the same, although in 2.1.4, there are no intermediate interfaces names vbox? and br?.

One change from the normal IPCop setup I would recommend is not to run a DHCP server on it, but instead to run one in the host OS which is why we installed dhcp3-server. That way, if IPCop fails to start, at least the clients on your network can get an IP address to work with.
Edit /etc/default/dhcp3-server and set the interface to br0. Have something like this in /etc/dhcp3/dhcpd.conf. Tailor to suit your LAN.

ddns-update-style none;
option domain-name "localdomain";
option domain-name-servers;
default-lease-time 600;
max-lease-time 7200;
log-facility local7;
subnet netmask {
  option routers;

You will need to restart the host networking at this point. The clever way is:

/etc/init.d/networking restart
/etc/init.d/dhcp3-server restart

The blunt way is a reboot.

Now create a user to run the VM under and give it a password for logins.

useradd -u 65000 -g vboxusers -m ipcop
passwd ipcop

Now login as ipcop for the following steps.

Copy the ISO install image for IPCop to the host machine, in /tmp, as you can see below. Then set up a VM for IPCop from the command line. This VM has 32MB memory and a 500MB disk.

VBoxManage createvm -name IPCop -register
VBoxManage modifyvm IPCop -ostype linux24 -memory 32
VBoxManage createvdi -filename IPCop.vdi -size 500 -register
VBoxManage modifyvm IPCop -hda IPCop.vdi
VBoxManage modifyvm IPCop -nic1 hostif
VBoxManage modifyvm IPCop -nictype1 82540EM
VBoxManage modifyvm IPCop -nic2 hostif
VBoxManage modifyvm IPCop -nictype2 Am79C973
VBoxManage registerimage dvd $I
VBoxManage modifyvm IPCop -dvd $I

Activate the interfaces in 1.6.2

Add the interfaces needed by the VM:

VBoxAddIF vbox0 ipcop br0
VBoxAddIF vbox1 ipcop br1
VBoxManage modifyvm IPCop -hostifdev1 vbox0
VBoxManage modifyvm IPCop -hostifdev2 vbox1

End of 1.6.2 activation.

Activate the interfaces in 2.1.4

Bind the interfaces needed by the VM:

VBoxManage modifyvm IPCop -hostifdev1 eth0
VBoxManage modifyvm IPCop -hostifdev2 eth1

End of 2.1.4 activation.

Now let's start up the IPCop VM.

VBoxHeadless -s IPCop -a -p 4000

From another machine connected to the inside network running X, connect to the ipcop console with:

rdesktop -a 16

From Windows you can use the supplied Remote Desktop Client. You specify the host as

You will see the "console" of IPCop.

Do a standard install except that choose noscsi in IPCop install so that it doesn't attempt to probe for SCSI cards. The SCSI probes fail non-fatally, but mess up the screen and slow down the install. I will not describe the install here, there are IPCop documents for this. You will have to select Intel Gigabit NIC (e1000) for the first ethernet card in IPCop and assign this to GREEN, so that the pcnet32 NIC can be assigned to RED. Remember not to activate the DHCP server in IPCop since we have one running in Ubuntu.

After IPCop has been installed, shutdown the VM. Then we detach the ISO image so that it will boot from the "disk" next startup.

VBoxManage modifyvm IPCop -dvd none

Now we need to make IPCop start at boot time. Here's a SysV init script to do this. This is for Ubuntu/Debian, you'll have to do the equivalent in other Linux distros. Put it in /etc/init.d/vbox-ipcop. Activate at runlevel 2 with the sysv-rc-conf utility and make sure it follows vboxdrv and vboxnet in the bootup sequence, and precedes vboxdrv and vboxnet in the shutdown sequence.

# Start/stop the IPCop VM
# Provides:          vbox-ipcop
# Required-Start:    $syslog $time vboxdrv vboxnet
# Required-Stop:     $syslog $time
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: IPCop in Virtualbox VM
# Description:       IPCop in Virtualbox VM


test -f /usr/bin/VBoxHeadless || exit 0

. /lib/lsb/init-functions

case "$1" in
start) log_daemon_msg "Starting IPCop in Virtualbox" "VBoxHeadless"
 mkdir -p $VARRUNDIR
 chgrp vboxusers $VARRUNDIR
 chmod g+ws $VARRUNDIR
        USER=$VBOXUSER LOGNAME=$VBOXUSER start-stop-daemon --start --quiet --background --make-pidfile --pidfile $PIDFILE --name VBoxHeadless --chuid $VBOXUSER --startas /usr/bin/VBoxHeadless -- -s IPCop -a $VRDPADDR -p $VRDPPORT
        log_end_msg $?
stop) log_daemon_msg "Stopping IPCop in Virtualbox" "VBoxHeadless"
 su -c '/usr/bin/VBoxManage controlvm IPCop keyboardputscancode 1d 38 53' $VBOXUSER
 sleep 30
 start-stop-daemon --stop --quiet --pidfile $PIDFILE --name VBoxHeadless
 rm -f $PIDFILE
        log_end_msg $?
 $0 stop
 $0 start
 su -c '/usr/bin/VBoxManage showvminfo IPCop' $VBOXUSER | grep '^State:'
*) log_action_msg "Usage: /etc/init.d/vbox-ipcop {start|stop|restart|status}"
        exit 2
exit 0

The shutdown part of the script sends a Ctrl-Alt-Del to the VM. However in the default IPCop installation, this reboots the machine. So login to the IPCop VM and edit /etc/inittab, changing the line with shutdown to halt the machine instead. It should look like this after the change.

ca::ctrlaltdel:/sbin/shutdown -h now

The shutdown part is not ideal, it assumes that the machine has been halted within 30 seconds before terminating it anyway. If you come up with a better way, please let me know.

You can now lock logins to the ipcop user account if you wish, since startup is from system scripts now. On the other hand it might be useful for debugging using manual startup. Then again, you can "become" ipcop using su -.

usermod -L ipcop

At the time of writing there is one update you should apply to IPCop to bring it up to 1.4.21. This is a standard IPCop update maneuver so I won't describe it here.


Remember that Virtualbox relies on a kernel driver to run. If you update the kernel, the driver will probably be invalidated, and you will not be able to start Virtualbox. Since your firewall is run in Virtualbox, you have painted yourself into a corner. Therefore do not remove the previous version of the kernel until you have the packages needed to make Virtualbox run in the new kernel. For the OSE this will be a release of Virtualbox that is compatible with your new kernel. For the Sun version, it will be the kernel source package to the new version so that you can rebuild the driver with:

/etc/init.d/vboxdrv setup

Is it safe?

The question should be: Are any additional dangers introduced by the use of bridging through a non-firewall host? I believe they are minimal, as the packets only traverse the host firewall, which should be iptables and as good as IPCop's, and the tap driver, which is straightforward and does no interpretation of the packets. Just make sure you never assign an IP address to the outside ethernet interface or bridge in the host OS, otherwise services will bind to that address and will be reachable from the outside. Eventually, you have to decide for yourself. I'd be interested to hear if you have concrete arguments one way or the other.