How to create a wireless pen testing lab

In my previous rant I was telling how notoriously difficult is to get the right hardware. If you get an AP for this reason, chances are it wont work as expected. Finding information about various models is next to impossible.

My solution is: get a bunch of USB adapters, then use virtual machines. You need a hypervisor with proper USB passthrough support though. Unfortunately, VirtualBox won’t cut it.

Hypervisor recommendations: VMware Player (Windows, Linux), KVM (Linux, untested for this particular setup), VMware Fusion (OS X), Parallels Desktop (OS X, untested for this particular setup). Unfortunately, for OS X there’s no free/freeware product with proper USB passthrough support. Bear in mind that virt-manager makes things easier for KVM under Linux. This brings KVM close to the usual desktop solutions.

I use three virtual machines with three USB adapters, but at minimum you need two VM’s and two adapters if you don’t need remote connectivity to your lab. The wireless client might be any device if you’re near the machine (phone, tablet, etc). The adapters that you need to use for monitor mode and wireless client may need to have removable antennas.


I found out that an adapter with AR9271 proved to be the best choice for the AP VM. That is, from my collection of USB adapters. For example, I use a TP-LINK TL-WN722N. It is inexpensive and easily available. I mounted the antenna on the AP adapter.

For the VM itself, I use Ubuntu 14.04 with hostapd and dnsmasq. I removed the network-manager package and configured the wired interface by editing the /etc/network/interfaces file.

I placed the hostapd configuration in /etc/hostapd/hostapd.conf:


# WEP config
# 1 = open
# 2 = psk
# 3 = both

# WPA config
# 1 = WPA
# 2 = WPA2
# 3 = both
# TKIP CCMP = both

This configuration is for WEP with open authentication. The comments help you to use this as a template for configuring WEP with PSK, WPA, or WPA2. If you comment the WEP config and uncomment the WPA config, it will default to WPA2.

The dnsmasq config was placed in /etc/dnsmasq.conf:

# disables dnsmasq reading any other files like /etc/resolv.conf
# Interface to bind to
# Specify starting_range,end_range,lease_time
# dns addresses to send to the clients

For starting the AP, I use this script:

#Initial wifi interface configuration
ifconfig $1 up netmask
sleep 2
###########Start dnsmasq, modify if required##########
if [ -z "$(ps -e | grep dnsmasq)" ]
#Enable NAT
iptables --flush
iptables --table nat --flush
iptables --delete-chain
iptables --table nat --delete-chain
iptables --table nat --append POSTROUTING --out-interface $2 -j MASQUERADE
iptables --append FORWARD --in-interface $1 -j ACCEPT
sysctl -w net.ipv4.ip_forward=1
#start hostapd
hostapd /etc/hostapd/hostapd.conf
killall dnsmasq

I placed it into a $PATH directory. Invoke it with:

sudo initSoftAp wlan0 eth0

The script runs in foreground. It can be easily killed with Ctrl+C. You may easily observe the hostapd log messages for debugging reasons. The subnet for this lab AP is different than the subnet used by the eth0 interface of the VM. It’s irrelevant if the VM itself uses NAT or bridge for its “wired” interface.

The monitor mode VM

I use an ALFA AWUS036H simply because I have it. It uses the RTL8187L chipset which is old, but well supported. You may pick any adapter that properly supports packet injection. I started a project to document this. I call it aircrack-db as I use the aircrack-ng suite for testing the wireless interfaces capabilities.

I took down the antenna of this adapter because of the receiver saturation. It is too close to the AP and using long USB cables isn’t feasible in my case. Taking the antenna down and placing the cards apart at about half a metre provides the best results. The aircrack-ng FAQ explains this: Why do I have bad speeds when i’m too close to the access point? If you keep the antenna, you may see good quality signal (PWR -19 or so), but the RXQ shows that something is wrong. Most of the time, this setup is going to be useless, therefore only the AP or the attacking card needs to have the antenna, or place them far away from each other.

For the VM itself I use Kali 1.0.9a (aka the latest, up to date, version). You may also remove network-manager from this machine and configure eth0 via /etc/network/interfaces. The network-manager usually is troublesome together with the aircrack-ng suite. In my case, “airmon-ng check” returns nothing.


This is optional if you don’t need remote connectivity to the wireless pen testing lab. If you do, this is my setup.

I use an ALFA AWUS051NH simply because I have it. I also use a Netis WF2190 from time to time. This adapter doesn’t need to support monitor mode. It just needs to act as a wireless client in order to test various scenarios where an associated STA to the AP is required, or if you target an unassociated client with airbase-ng.

I use Ubuntu 14.04 and that’s pretty much it. It doesn’t need any modifications as the network-manager is actually useful in this case. Sometimes, the AP disappears after repeated deauth attacks. If this happens, you need to uncheck “Enable WiFi” from the network manager menu, and then enable back the WiFi.

If the AP adapter has its antenna, then take down the antenna of the wireless client adapter. The receiver saturation in this case means really erratic behaviour such as connections timeouts to the AP or really slow association.

Leave a Reply

Your email address will not be published. Required fields are marked *