A Simple OpenBSD Router For Your Virtual Machines

Why Do I Need A Separate Router For Virtual Servers?

I tend to use VirtualBox a lot at home for experimenting with different operating systems or trying out scenarios that are too dangerous to “do it live”. While I could just give these virtual machines a bridged connection, I like to try to keep things as close as possible to the original environment, especially for “forensic” inspections.

In order to do this I have come up with a very basic OpenBSD setup that allows me to adapt the router/firewall to the virtual machine rather then make modifications to the image. Using the PF firewall, we will be able to rapidly assemble a NAT’ing firewall. With additional research you, thanks to PF’s awesome documentation, you should be able to extend this to be a traffic logger, export to netflow and do many other things.

I have tried experimenting with many “embedded” Linux distros that are targeted more at a hardware appliance, but in the end all of the user friendly settings just ended up getting in the way. Using OpenBSD I am able to get a very low footprint OS with a well-documented and transparent firewall. I know precisely what PF is doing with my packets.

While this setup was done on VirtualBox, it could easily be adapted to any virtual host environment that allows for Bridged and Internal NICs to be assigned.

Creating the Virtual Machine

For me, Virtual Box is my go to virtual platform for experimentation. The interface makes sense and gets out of my way when creating virtual machines. Virtual HDD’s and ISOs correspond to real files in your host machines OS, not an abstracted storage device.

For long running servers I prefer ESX, but for just playing around Virtual Box is the way to go.

  • Download and install Virtual Box for your OS
  • Download load “cd50.iso” from a mirror at http://www.openbsd.org/ftp.html#http. This is the base install iso with no extras, we’ll be adding some software as part of the install process.
  • Create a new VM in VirtualBox
    • 32 MB RAM
    • 600 MB HDD (This leaves about 100 MB of free spaces for logs and additional packages)
  • Edit your network settings and add an additional NIC. Set the first one to Bridged or NAT and the second one to Internal

Base Installation

Though this is a text based installer (a dying breed) the install is very straight-forward with logical defaults. For the most part you can just hit enter.

  • “I” install
  • Choose Keyboard
  • Set hostname
  • Configure bridged/NATd nic for downloading installation files
  • Set your password
  • Start ssh – Yes
  • Start Ntp – Yes – set to your favorite ntp server (pool.ntp.org)
  • Do you expect to run X Windows – No
  • Setup default user (your choice)
  • Set your timezone
  • Setup the disk
    • Which one is the root disk – wd0
    • Use DUIDs – yes
    • Use whole disk – whole
    • Use auto layout
  • Location of sets – http
  • Accept defaults for server, path locations
  • Set names – type “-x*” to deselect all of the X Windows packages
  • Set names – done
  • There may be a few additional questions about setting the time, adding non-free items to the boot process, just answer as necessary
  • At the end you’ll be dumped to a shell prompt, type “halt” to shutdown.  Power off and remove the virtual cd.  Power back up

First boot config

Surprisingly, we are nearly done. Only a few touches are needed to enable NAT and turn on the minimal firewall settings to allow traffic out.

Configuring Basic Networking

First we will need to setup our network interfaces. After going through the install your primary interface (em0) should already be setup, but lets review. Network configuration is done by editing the file /etc/homename.interface, for example /etc/hostname.em0. I have mine set as below, adapt as needed.

/etc/hostname.em0dhcp
/etc/hostname.em1192.168.1.1 255.255.255.0

Next we’ll set the nameserver, if you set your primary to use DHCP in the install process this will already be filled in by the values from your DHCP server.

/etc/resolv.confnameserver 8.8.8.8

And finally setting the gateway. Again, if you’ve set your interface to DHCP it will be set by the DHCP server and this file will not be created, otherwise:

/etc/mygate10.0.0.1

Now to restart the network interfaces and settings, run the following:

sh /etc/netstart

Turning on IP forwarding

IP forwarding is controlled by the sysctl mechanism. In *BSD, sysctl is basically a way to tweak various kernel settings. Being built into the kernel these pieces are generally more low level and higher performance than a “user land” application. For a one-time change you can use the sysctl command to tweak settings. To make these settings persist over reboots, we will be setting them in the /etc/sysctl.conf file.

Edit /etc/sysctl.conf with your favorite editor (vi and mg – MicroGnuEmacs are among those included). Find the line that says:

#net.inet.ip.forwarding=1

and remove the comment

net.inet.ip.forwarding=1

Setting up PF the Packet Firewall

Now we have turned on the IP forwarding mechanism in the kernel we need to enable the PF firewall and tell it how to route traffic.

First, we will enable the firewall. This is done by simply editing /etc/rc.conf which is somewhat like a master settings file. In here you will find various settings relating to which applications should be running at boot and what settings they take. To turn off an application it is set equal to NO, otherwise it is a “” or some setting inside quotes, such as “en0″. The comments do a good job of explaining these options.

What we are looking for is the line:

pf=NO

set this to:

pf=YES

That’s nearly it!

Configuring PF

Now for the most difficult part. Seriously, this is pretty easy stuff right?

We will be editing the settings file for PF, /etc/pf.conf. At the top you will notice some default settings, leave these.

At the bottom of the file we will add the following line:

pass out on em0 from em1:network to any nat-to (em0)

What this will do is fairly easy to understand once you realize that the PF configuration is it’s own mini language ( or Domain Specific Language )

Rules are essentially built up like this: action direction on interface from/to destination

pass out on em0 – allow traffic outward from em0 (our “external” interface)

from em1:network – this is shorthand to say “whatever IP network we have assigned to em1“, em1 being our internal interface.

to any – we don’t care where the traffic is destined for

nat-to (em0) – perform NAT on the traffic to make it appear as if it’s coming from em0. With the parenthesis around em0 we are telling PF to continually update the IP of this interface, as it may change – for example with a cable modem

Finishing up

You could manually activate all of the changes we have made using the sysctl and pfctl commands, but I find it easier to just reboot. A quick reboot will also prove that all of the services will start up correctly.

I hope this little BSD firewall is useful to you. It can easily be adapted to be a DHCP server, DNS server, or provide many other network services. This will help you in building up your virtual network for testing or replicating an existing environment for experimentation with captured P2V machines.


Edit 2013-09-15 – I fixed a few spelling mistakes since this has frequently been a very popular post on this site. If you have suggestions or articles you’d like to see in this format please drop me a line at zach@thehelpfulhacker.net or post a comment. Cheers

Share

10 Comments

  1. gabe says:

    Nice, I do almost the exact same thing for my VM’s. A nice OpenBSD VM with 64MB’s of ram serves nicely to firewall/NAT my “virtual machine network,” and lets me play around with things before putting them on me “real” OpenBSD router (:

  2. nonsoike says:

    I have used Vyatta 6.0 and Vyatta 6.3 for over 4 years now both as a test router and as an enterprise gateway router. I have run them in both VMware virtual machines and physical machines and I have not seen any reason to change. The documentation is excellent and you will find anything you will need for networking: firewalling, NATing, VPN, Packet Monitoring, Intrusion Prevention System etc.

  3. Matt says:

    This is a very cool tutorial. I’m going to build a home gateway based on Linux and this will be a great jump-start. I was thinking OpenBSD. :)

  4. Sum Yung Gai says:

    Been using an OpenBSD router for some time now. Also acts as an anti-spam filter. OpenBSD rocks for this task, and several others.

  5. […] A Simple OpenBSD Router For Your Virtual Machines I tend to use VirtualBox a lot at home for experimenting with different operating systems or trying out scenarios that are too dangerous to “do it live”. While I could just give these virtual machines a bridged connection, I like to try to keep things as close as possible to the original environment, especially for “forensic” inspections. […]

  6. […] posted here: The Helpful Hacker – A Simple OpenBSD Router For Your Virtual … Štítky:openbsd […]

  7. Aaron Mason says:

    Has anybody gotten this to work with CARP? It works beautifully with a single NIC but as soon as you add failover, it fails, which really sucks because it will happily do DHCP (provided you run dhclient after the interface is set up otherwise it’ll be stuck in INIT phase) and the internal CARP is fully accessible. I just can’t get any further than that.

    Then again people have been reporting strangeness from CARP since upgrading, might try 4.9 and see if it works there.

  8. Nick B. says:

    Nice article. I’ve used a variation of this to provide IPv6 to virtual machines and the host. Rather than change rc.conf I add overrides in rc.conf.local.

  9. dean says:

    how about transparent proxy rules ?

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre user="" computer="" escaped="">