8. [Optional] Connecting to the Outside World

When you are done, and looking for something else to spark your interest, you might try these optional activities.

In this optional section, you’re going to add another adaptor to R1, connected via Virtualbox NAT, and advertise this as a default route to the rest of the network.

Add an extra adaptor to one of the routers with a VirtualBox NAT type interface and originate a default route using RIP. The interface will have to be configured via DHCP (as a client). You should now be able to access the network beyond the host using TCP services such as SSH; note that ping won’t work, as the VirtualBox NAT adaptor can’t support ICMP.

Note that it is not our router that is performing the NAT, but rather some VirtualBox device just beyond. We shall be investigating doing NAT ourselves in the next lab.

Because we’re going to need VirtualBox’s NAT system to know more about our network (in order to figure out where to route traffic coming back into the network), we’re going to require something a little more complex with regard to how we configure VirtualBox to do the NAT. To do some of this, we have to use the command-line management tool VBoxManage instead of the GUI.

Make sure you have saved your configuration on R1, and shutdown the system gracefully. Then, on a terminal window on your Mac workstation, run the following commands:

Add Adaptor 3 (eth2), which is a NAT adaptor
$ VBoxManage -q modifyvm IntRoute_R1 \
>   --nic3 nat \              Make Adaptor 3 connected via VirtualBox NAT
>   --nictype3 virtio \       Setting adaptor type [performance]
>   --natnet3 "192.168/16" \  Use 192.168.x.x instead of 10.0.x.x
>   --natdnsproxy3 on \       Advertise DNS server at 192.168.0.3
>   --natdnspassdomain3 off   Don’t advertise DNS search path of host

Now start R1, and configure the new interface:

$ configure
$ set interfaces ethernet eth2 address dhcp
$ commit
$ run show dhcp client leases
interface  : eth2
ip address : 192.168.0.15         [Active]
subnet mask: 255.255.0.0
router     : 192.168.0.2
name server: 192.168.0.3
dhcp server: 192.168.0.2
…

Note that the subnet our interface is placed in is 192.168.0.0/16, which is good for us because it means all of our addresses in our network fall under that. In essence, we have hierarchical addressing. As far as our gateway to the outside world (VirtualBox NAT) is concerned, anything addressed to something in 192.168.x.x will be sent onto the local network which R1’s eth2 interface will be attached to.

This means that traffic coming from the outside that ought to be routed via R1 as the next-hop, will not. Take for example traffic returning to C2 (192.168.5.10). VirtualBox will think that it should be a local delivery, so will ARP for C2’s hardware address. We work-around this problem (solving the problem properly involves being able to add a route entry to VirtualBox’s NAT engine) by enabling Proxy-ARP on R1’s eth2 interface: set interfaces ethernet eth2 ip enable-proxy-arp.

The VirtualBox manual states that, given the configuration used above, the only addresses that are used are 192.168.0.15 for the guest, 192.168.0.2 for the router and 192.168.0.3 for the DNS name server. Thus, we can set aside 192.168.0.0/24 in our addressing plan as being used for the network between R1 and the VirtualBox NAT, which conveniently leaves the rest of our network unchanged.

After you’ve added and tested the interface, test connectivity. Remember though, that we cannot use ping to test because the VirtualBox NAT doesn’t support ICMP. R1 was configured with DNS settings via DHCP, so we should be able to resolve hostnames. We can also try using test-by-doing.

$ host gallardo.otago.ac.nz(or anything else). Should work fine.
$ ssh user@gallardo.otago.ac.nz(or to anywhere else). Should work fine.

On all other hosts and routers you will want to set the DNS nameserver to 192.168.0.3. On Vyatta, this can be done using set system name-server 192.168.0.3. On Linux guests, just put nameserver 192.168.0.3 into /etc/resolv.conf.

Now all you need to do is advertise the default route via RIP. Because default routes catch a lot of traffic, and can be problematic with regard to routing loops, there are protection measures in place to ensure they are not accidentally advertised.

On Vyatta, we tell Vyatta that we want to originate default route information using the configuration command set protocols rip default-information originate (this is the sanity check), and advertise the default route using set protocols rip network 0.0.0.0/0. There are no special configuration elements you need to put into the receiving routers, just use the operational command show ip route to verify that the other routers now have a default route, learned via RIP.