VirtualBox Wireless Bridging with DHCP

Posted by admin on September 12, 2008 under Tech Tips | Be the First to Comment

WARNING! THIS POST HAS BEEN MARKED AS OUTDATED!

While there may be useful information still contained within the article, there may be other more relevant articles out on the Internet. Please pay close attention to version numbers of software that this article refers to. If you’re not careful, you could break your system if you do not understand what you are doing. If you would like to see this article updated, please contact the site administrator using the Contact page. Thanks!

UPDATE (12/13/2009): The latest versions of VirtualBox 3 have made great improvements in their guest networking options. It is possible to natively bridge guests over your hosts wireless connection “out of the box”, even allowing guests bridge over wireless with DHCP. The suggestions on this post still work fairly well, and will be left up as it has bits of information that is still useful in some scenarios. Please refer to the latest VirtualBox documentation for more help.

ORIGINAL: In the following instructions, we’ll explore a couple of methods on how to let your VirtualBox guest use the DHCP services of your host’s wireless network.

In a previous post, I outlined how to bridge a VirtualBox guest across the wireless connection of your host.  But the process involved using static IP’s for your guest, because unlike a true bridge, your host is actually acting as a router, forwarding only unicast packets between the two networks.  This complicates your guests ability to use DHCP, since broadcasts are typically not forwarded by routers.  I’m going to demonstrate two methods that work around this limitation.  For the first method, we’ll be using two different DHCP relay agents. For the second method, we’ll simply use a Broadcast Relay Agent.

Network Assumptions

I’m going to assume we’re using a very simple setup typical to most small networks and wireless routers. Feel free to adjust the following values according to your own requirements.

Wireless Network ID: 192.168.1.0/24
Wireless Network DHCP Range: 192.168.1.2-100
Wireless Network DHCP Server: 192.168.1.1
Host Computer Wireless Interface: wlan0 (change accordingly)
Host Computer Wireless IP: Any IP (Doesn’t matter; You can use DHCP or static)
Host Computer TAP Interface IP: 192.168.1.150/32 (choose something outside DHCP range)
Guest Computer IP: DHCP/Dynamic

Getting Started

Enable IP forwarding on your host.

sudo sysctl net.ipv4.ip_forward=1

Install the User Mode Linux utilities, for the tunctl application.

sudo apt-get install uml-utilities

Create a TAP interface and give it a static IP address in the same address space as your wireless network.

sudo tunctl -u $USER
sudo ip addr add 192.168.1.150/32 dev tap0
sudo ip link set tap0 up

The IP address you choose for the TAP interface should be outside the DHCP range to prevent conflicts with other hosts. It’s very important that you don’t use the same subnet mask as your wireless interface, because you can run into unpredictable routing behavior on your host. I recommend using a 32-bit subnet mask as it is very clean and efficient. I like to use the ipcommand, but feel free to use ifconfig to accomplish the same thing.

Proxy ARP Required

Unlike in the previous post, unless you are reserving an IP address for your guest on the DHCP server, you may not know what IP address your guest will receive. In order for kernel based proxy ARP to work, you would need to manually add the assigned IP address to your routing table.

So to make things easy for you, parprouted comes to the rescue.

sudo apt-get install parprouted

When you run parprouted, it inspects ARP traffic on both sides of the network and adds IP addresses as host routes in the routing table. Run this command in one terminal so you can check out what’s happening in the background.

sudo parprouted -d wlan0 tap0

Method 1: DHCP Relay Agent

DHCP Relay Agents are commonly used on routed networks with centralized DHCP services. The relay agent is a service that is typically configured on a router and converts DHCP broadcasts into unicast messages directed at the DHCP servers IP address. For more detailed explanations on the matter, check out RFC 3046 and 1542.

Simon Kelley’s DHCP Helper (Option A)

I selected to discuss Simon Kelley’s DHCP Helper first because it really is a brilliantly simple and intuitive application. The primary advantage it has over ISC’s DHCP Relay is that you do not have to configure the application with the IP address of the DHCP server. You simply tell dhcp-helperwhich interface on which you want it to automatically discover the dhcp server via broadcast, and it does the rest for you!

Install dhcp-helper from your repositories, or download the latest source code here.

sudo apt-get install dhcp-helper

The service starts on installation automatically, listening on interface eth0. You’ll want to configure it in the file /etc/default/dhcp-helper. I am adding “-i wlan0” because by default it will listen on all other interfaces as well. This way, we limit the test to your VirtualBox guest.

DHCPHELPER_OPTS="-b wlan0 -i tap0"

Restart the service.

sudo /etc/init.d/dhcp-helper restart

Configure your VirtualBox guest to use tap0 as it’s network interface, and watch it pull an IP address from your DHCP server!

ISC’s DHCP Relay (Option B)

First of all, if you would rather use ISC’s DHCP Relay, you must remove dhcp-helper discussed in the previous section. It’s not as transparent as dhcp-helper, so I’m just mentioning it here for the sake of completeness.

Ubuntu and Debian repositories provide ISC’s DHCP relay agent in the dhcp3-relay package. For other distros, check your repositories accordingly.

sudo apt-get install dhcp3-relay

The installer will prompt you to add the IP address of your DHCP server and the interface you wish to listen on, etc. Simply leave them blank for now, as for this example, we’ll be testing things out from a command line. To test things out, run the following command from a separate terminal window, where the IP address is that of your DHCP server.

sudo dhcrelay3 -d -i wlan0 -i tap0 192.168.1.1

Configure your VirtualBox guest to use tap0 as it’s network interface, and watch it pull an IP address from your DHCP server!

Method 2: Broadcast Relay

Okay, so I’d love to take the credit for this one, but a reader from a previous post, Nick Knight, pointed me to a utility called bcrelay. Now this application is cool! It totally mitigates the need for a DHCP relay agent (so kill that process if you are running it), as bcrelay simply rewrites the layer-2 header and forwards broadcast messages between network interfaces. In the case of DHCP, the source MAC address of the packet is changed to your host machines address, but the DHCP header is untouched. So the DHCP server will still offer a brand new IP address to the guest.

Install and run the application from a separate terminal window. As a reminder, you still need to use parprouted though in another window.

sudo apt-get install bcrelay
sudo bcrelay -i tap0 -o wlan0

Configure your VirtualBox guest to use tap0 as it’s network interface, and watch it pull an IP address from your DHCP server!

Troubleshooting

If you really want to see all the action, use wireshark or tcpdump to inspect traffic. The following capture filter works well, in two separate terminals of course.

sudo tcpdump -eni tap0 udp port 67 or udp port 68 or arp or icmp
sudo tcpdump -eni wlan0 udp port 67 or udp port 68 or arp or icmp

Also, these commands are useful as well.

watch -n1 route -n
watch -n1 arp -an

If you need to figure out what is going wrong, be sure to stop all the components of the appropriate method and run them in the foreground in separate terminals. e.g. parprouted, bcrelay, dhcp-helper, dhcp3-relay. Most will give you clues as to what is failing.

Now.. I should mention, I ran into all sorts of issues when trying to get all of this to work. The methods that gave me the most trouble were the DHCP relay agents.

I have an Actiontec MI424WR router that royally screws up my DHCP relay agent’s packet exchange. I wasn’t getting any DHCP offers with unicast packets sent to the router. Apparently, during a typical non-relayed DHCP exchange, I was able to see that the router’s source MAC address was completely different in broadcast DHCP offer packets than what it’s IP address is actually associated with, so my unicast packets were probably being dropped by the router. I’m assuming this is some type of internal bridge interface dedicated for DHCP services or something, so I ended up having to install a separate DHCP server for this to work. ISC’s DHCP server worked completely normal, and I suspect this is entirely the routers fault.

Conclusion

If you do want to use this configuration regularly, I recommend the combination of parprouted and bcrelay or dhcp-helper. Both can be run in the background easily, and requires almost zero configuration if traveling between multiple networks.

However, as you have probably gathered, both methods described above are a bit complicated, and I don’t necessarily recommend it for every day use. I did it because I’m a geek, and I wanted to prove it could be done. While the process of setting up the entire environment could be made simpler with scripts, the challenges you will face on each wireless network might make the process of troubleshooting counterproductive. Many of the headaches you will face will be related to the wireless network hardware, such as centralized wireless solutions that restrict the number of MAC to IP addresses in order to prevent MITM attacks, and of course in some cases, charge you appropriately.

The best solution for public hostspots and corporate networks is still good old fashioned NAT. But this way sure is is a lot of fun and a good way to waste your weekend to impress all your other nerd buddies.