Monthly Archives: July 2014

Router Distro Headaches

I mentioned Voyage Linux as the os on my virtual routers. Recently I’ve also been trying to get a couple of others working. Namely, ZeroShell and PFSense.

ZeroShell Is working as a VM but I haven’t got it doing that much. I mainly want to test it as a wireless AP and possible Radius server. It only supports Atheros wireless chipsets of which I have none. The Atheros USB adapter I found may not be entirely straight forward in use it seems. I plan at some point to try this on a PC Engines borrowed Wrap or Alix. as

The appeal of the Debian based ZeroShell to me is that it can be configured through a web based gui. It has a lot of features and the ability to unlock other packages by making a contribution. The 3G failover capability is particularly intriguing but alas I’ve not had much luck with a Huawei E303 dongle.


PFSense is a FreeBSD based router / firewall, again with a web based gui. I have been trying to get this booting on the aforementioned Alix, as it’s setup as a DHCP server out of the box. This hasn’t worked as yet despite following their instructions, updating the Alix bios and so on.

More hopefully when I make progress.

VMWare Virtual Network Lab Setup

Example virtual lab using VMWare. I’ll refer to this as Vlab 1 in case I mention it in latter posts.

The general objective is to set up a small virtual network on which I can build. The virtual machines on the network will access the real network and thus the internet through one of them acting as a gateway.

I’m using 4 headless VMs, all running the Debian based Voyage Linux distro, which is tailored for router applications.

One of these VMs will be bridged to my real LAN, the one simulating an internet gateway. It will perform NAT for the networks behind it on the virtual side.

As an aside, these are running single area OSPF with the Quagga router software but I’ll just talk about the basic interface setup in this post.

Let’s call the 4 Voyage routers alpha, beta, gamma, delta. For what it’s worth, they are all installed in 2GB virtual disks, have one processor core each and 256MB RAM.

Alpha will be the gateway. i.e. the one with a bridged interface to the real network. The 4 VMs are connected in a simple line. Alpha – beta – gamma – delta.

In VMWare’s Virtual Network editor, I’ve configured 3 Vnets for these links. For some reason, it seems you can’t use a /30 subnet for Vnets. Which would be the usual point to point link. Virtual Network Editor just won’t allow it. SO I’m using /29’s.

In my case, Vnets 11, 12, 13.

Vnet 11.
Link between alpha and beta.

Vnet 12.
Link between beta and gamma.

Vnet 13.
Link between gamma and delta.

Alpha has 2 interfaces, one on the real LAN.

And the Host Only Custom link to beta.

The rest are all Host Only Custom links in their respective Vnets.

Beta – alpha:

Beta – gamma:

Gamma – beta:

Gamma – delta:

Delta – gamma:


I have to be organised in how I set these up, more so than perhaps most people. As they’re running headless, no desktop, they have no screenreader running. It may be possible to recompile Voyage with Speakup but that’s beyond me at the moment.

Normally when I’m experimenting with say a single virtual server, I’ll have one interface bridged to my real LAN so I can use my screenreader on the host and SSH in. In this case, I want to force all traffic through the virtual gateway and only have that machine appearing on the LAN. So to reach the others, I need to make sure the routing is setup as I’ll be SSHing to the gateway and hopping from there. As there’s no screenreader on the VMs I can’t just type at the consol.

How I’ve done this is initially set up all VMs with one bridged interface so I can connect and configure the other Host Only connections by editing /etc/network/interfaces. Once I know these are up and reachable from the other VMs, I shut down the bridged interface and comment it out.

As mentioned I am using OSPF and having alpha redistribute the default route that leads out on to the LAN. Were this not the case, I could have used a line in interfaces to set a static default route pointing to the Host Only interface. i.e. through the virtual network towards alpha and the real world.
Post-up route add default gw x.x.x.x

Whilst setting these up it might be worth noting, I did manage to mess up my SSH config file on one of the Vms after I’d already shutdown the bridged interface. Effectively locking myself out due to the no screen reader access on the consol. I fixed it by SSHing into another Voyage VM and counted down how many lines the errant line was. Then did this blind on the misconfigured machine. Cleverer people than I might have used Sed and Grep in some fancy way to fix it…



Voyage Linux

Intro to VMware’s Virtual Networks

I’m using the popular VMware Workstation 10 on Windows Seven. VMware have a number of products. You can download the free VMware Player if you want to run a compatible virtual machine but you can do more with Workstation. Of course there are a number of other virtualisation platforms for Windows, Mac and Linux but I’m with this one.

The Virtual Network Editor that comes with Workstation is where you can set up to 19 virtual networks. Before going on to look at that, note, Under VMware There are 3 types of network connection. NAT, Bridged and Host Only.

NAT. Network Address Translation. The NAT option creates a virtual network behind your host machine on which your guest resides. It has access to the real network resources through your host but doesn’t appear on the network to other devices on your LAN.

Bridged. This takes your virtual machine’s network adapter and bridges it through the host so the guest will appear on the LAN with its own IP address. Either a static one you configure on the guest or if you’re using DHCP, it will get one from your real DHCP server.

Host only. This configuration provides a virtual connection to another virtual machine. So you can have a network of completely isolated VMs if you choose.

Using the Virtual Network Editor, as an example we’ll add a virtual network for host only connection. This will act as a private network between 2 or more guests. The VMware virtual network editor found in the program group in start menu or just use the search, is where you initially set up virtual networks or Vnets. Some of these Vnets are configured by default. Vnet 0 provides the bridged connection. Vnet 8, is for NAT. Of this latter type, you can have only one anyway.

To add a custom Vnet click add. Choose the Vnet you want to use. You can think of these like virtual switches. When configuring guest’s network interfaces, you effectively connect them to these virtual switches.

Choose Host Only.

To have this network only be available to your guests, not your host. Untick Connect a Host Virtual Adapter to This Network.

VMware has its own DHCP server for these Vnets. In my case I untick this box as I want to either configure static addresses or set up a DHCP server on one of the guests themselves.

Next choose the IP and subnet you want for this network. Click OK, you’re done.

Now from within VMware, VM Menu, Settings, you can add or change the network adapter settings for the selected guest. For example from the Hardware tab, go to add and choose Network Adapter.

Choose the Host Only setting Click OK.

Highlight this new interface in the list view and select the Custom radio button. You can now choose the Vnet you configured earlier to which this virtual network interface will be connected.

Later I’ll give an overview of how I set up a small virtual network lab using these custom networks, with a guest acting as a router, linking them to my real network and thus internet access.