GNS3 - VirtualBox Part 8: Creating tun/tap and Cloud Devices

Describes how to configure persistent tun/tap devices and IP Masquerading on a host machine and connect to GNS3 Cloud Devices and virtual networks to the host and Internet.

9 April 2015 -- Important Update
If you install dynamips from source on Ubuntu, the executable will not have the correct permissions for tun/tap devices.  Change to the executable's directory (/usr/local/bin) and run the following command:

sudo setcap cap_net_raw,cap_net_admin+eip dynamips

Creating Persistent tun/tap Interfaces
Additional software is required to create the logical interfaces for cloud devices.

sudo apt-get install uml-utilities bridge-utils

The rc.local file is executed at boot time and configures persistent tun/tap interfaces.

tunctl -t tap0
sudo ifconfig tap0 172.16.100.1 netmask 255.255.255.0 up

tunctl -t tap1
sudo ifconfig tap1 172.16.101.1 netmask 255.255.255.0 up

tunctl -t tap2
sudo ifconfig tap2 172.16.102.1 netmask 255.255.255.0 up

tunctl -t tap3
sudo ifconfig tap3 172.16.103.1 netmask 255.255.255.0 up

exit 0

Once configured and executed, ifconfig will list devices tun0, tun1, tun2 and tun3.

Configuring Network Address Translation Masquerading on the Host Machine

There are numerous articles describing Network Address Translation (NAT) masquerading available.  For this example, the Webmin Firewall interface provides a graphical configuration tool to use the host wireless interface wlan0 for NAT masquerading.

Under the host's Webmin interface, navigate to Networking and select Linux Firewall.  In the upper left, select Network Address Translation (NAT) from the Showing IPTable pull-down menu.  There will be no rules configured.  NAT is a Post Routing action, so click Add Rule under the Packets After Routing (POSTROUTING) section.  In the subsequent screen, select the Masquerade radio button and change the Outgoing Interface section from <ignore> to Equals and select interface wlan0 as illustrated below.  Save this rule.

Make sure the Activate at Boot option is selected and click Apply Configuration.

This typically -- but not always -- applies the NAT.  You may wish to reboot at this point.

The /etc/network/interfaces for the host laptop only configures a loopback device at boot time.  Recall also the tun/tap devices are configured in the rc.local file.  Webmin's firewall module adds a line invoking the IPTables rules under the loopback device configuration:

iface lo inet loopback
    post-up iptables-restore < /etc/iptables.up.rules

The files /etc/iptables.up.rules generated by webmin is:

# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT
# Completed on Thu Jan 22 06:32:20 2015
# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT
# Completed on Thu Jan 22 06:32:20 2015
# Generated by iptables-save v1.4.21 on Thu Jan 22 06:32:20 2015
*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A POSTROUTING -o wlan0 -j MASQUERADE
COMMIT
# Completed on Thu Jan 22 06:32:20 2015

The most important line is:

-A POSTROUTING -o wlan0 -j MASQUERADE

Some variation of that command is required for masquerading.

Configuring OSPF Routing between the Host Machine and GNS3 Networks

Previous articles in this series have used Debian Linux VirtualBox Gateways to connect GNS3 networks to the host machine and Internet.  These Gateways require 160 - 192 MB memory each and each machines eth0 interface is VirtualBox bridged to the host machines wlan0 interface.  These work well, but four of them use 640 - 768 MB memory, not insignificant, when (by comparison) a Linux VirtualBox Nagios, Icinga or Zabbix server requires only 512 MB memory.  Converting to host machine tun/tap devices and GNS3 clouds frees up that memory for other purposes.

Debian Linux Gateways also present additional security issues.  In the illustration above, the top part depicts how the Debian Linux Gateways -- with eth0 bridged to the host's wlan0 interface -- require additional security.  Each Gateway's connection runs OSPF to share routes with the host using Area 192.168.0.0 -- the wireless LAN interface -- and must be secured (this network uses the FWBuilder application to configure IPTables) because they are exposed to the wlan0 network.  This may not be a issue at home, but is when connecting a laptop host to other networks.

Many articles are available describing how to configure static routes for tun/tap interfaces.  However, with multiple tun/tap interfaces, a routing protocol on the host machine is more flexible and reliable.  For instance, multiple Cloud Device - GNS3 router instances may be created with automatic host-GNS3 and GNS3 virtual router updates.  GNS3 routing topologies may be created and modified as needed and the host machine's routes to GNS3 devices will automatically update.  In the illustration above, the bottom part depicts how only one interface -- the host's wlan0 -- is exposed.  The cloud devices, running on tun/tap interfaces, must route through the host for Internet and wireless network access.  The tun/tap device addresses and networks are merely added to the host's OSPF process.  Routing from the GNS3 virtual network to the Internet is provided by the host's NAT masquerade rule.

To configure routing for GNS3 Cloud devices, add the tun/tap interface networks to the OSPF configuration in the Quagga routing process.  Also, the host must originate default routes for the GNS3 routers.  For the four tun/tap devices already configured:

network 172.16.100.0/24 area 0.0.0.0
network 172.16.101.0/24 area 0.0.0.0
network 172.16.102.0/24 area 0.0.0.0
network 172.16.103.0/24 area 0.0.0.0 

default-information originate always

Migrating from VirtualBox Debian Linux Gateways to GNS3 Cloud Devices

Migrating the network used in this series from VirtualBox Debian Linux Gateways to GNS3 Cloud devices is, at this point, rather simple:

1. Remove the VirtualBox Debian Linux Gateways
2. Add GNS3 Cloud Devices configured for host tun/tap interface
3. Change existing GNS3 router's IP addresses and OSPF networks

When the VirtualBox Gateways are removed there are no routes from the host to the GNS3 network.  The route command on the host will only list its default gateway, wireless network and the four tun/tap interface networks.

Once the first tun/tap device is connected to a cloud and the GNS3 router updated (Coudersport_Cloud in this example), the host will establish an OSPF adjacency and have routes to all GNS3 networks through interface tap0.

As each of the remaining three Cloud Devices are added, new shortest path routes appear in the host's routing table.  For instance, when adding the Philadelphia_Cloud device, the route to network 10.64.0.0 255.248.0.0 changes from tap0 to tap1 (from 172.16.100.2 to 172.16.101.2).  Upon completion, there will be routes from the laptop through each of the Cloud devices tap0, tap1, tap2 and tap3.

The video below depicts the process.