NETinVM: November 3, 2016

About Release

Back to the Top


Back to the Top
Please remember that VulnHub is a free community resource so we are unable to check the machines that are provided to us. Before you download, please read our FAQs sections dealing with the dangers of running unknown VMs and our suggestions for “protecting yourself and your network. If you understand the risks, please download!


Back to the Top


A tool for teaching and learning about systems, networks and security

Authors: Carlos Perez & David Perez Date: 2016-11-03


NETinVM is a VMware virtual machine image that provides the user with a complete computer network. For this reason, NETinVM can be used for learning about operating systems, computer networks and system and network security.

In addition, since NETinVM is a VMware image, it can be used for demonstrations (i.e. in classrooms) that can be reproduced by students either in a laboratory or on their own laptop and thus, at home, at the library... For these reasons we present NETinVM as an educational tool.

Description of NETinVM

NETinVM is a VMware virtual machine image that contains, ready to run, a series of User-mode Linux (UML) virtual machines. When started, the UML virtual machines create a whole computer network; hence the name NETinVM, an acronym for NETwork in Virtual Machine. This virtual network has been called '' and has fully qualified domain names defined for the systems: '', '', etc.

All of the virtual machines use the Linux operating system. The VMware virtual machine is called 'base' and it runs openSUSE 13.2. User-mode Linux machines use Debian 6.0 and they have different names depending on their network location, because they are grouped into three different subnets: corporate, perimeter and external. The subnetworks are named 'int' (for internal network), 'dmz' (for DMZ or demilitarized zone, usually used as a synonym for perimeter network) and 'ext' (for external network).

One of the UML machines, 'fw', interconnects the three networks ('int, 'dmz' and 'ext'), allowing for communication and packet filtering. The rest of the UML machines have only one network interface, connected to the network they are named after:

int<X> + UMLs connected to the internal network. can take values from 'a' to 'f', both inclusive. These machines only offer SSH service by default.

dmz<X> + UMLs connected to the perimeter network (DMZ). They are supposed to be bastion nodes. Two preconfigured bastion nodes are provided, each one with its appropriate alias: + 'dmza' is aliased as '' and it offers HTTP and HTTPS services. + 'dmzb' is aliased as '' and it offers FTP.

ext<X> + UMLs connected to the external network (ie: Internet). Because a picture paints a thousand words, or so they say, the following figure shows NETinVM with all of the virtual machines running inside.

General view of NETinVM in VMware. The document example-net.pdf offers a detailed view.

All of the elements referenced before are shown in the image with their IP and ethernet addresses. The following rules have been used for assigning addresses:

In addition to the computers and networks already described, the figure also shows the real computer where NETinVM runs ('REAL COMPUTER') and VMware Player's typical network interface ('vmnet8'), which optionally interconnects NETinVM's networks with the external word.

When they boot, all UML virtual machines get their network configuration from 'base', which provides DHCP and DNS services to the three NETinVM networks through its interfaces 'tap0', 'tap1' and 'tap2'.

Routing works as follows:

Communication between 'base' and any UML machine, in both directions, is direct, without going through 'fw'. (When the communication is started from a UML machine, the IP address of the interface of 'base' in the corresponding network must be used.) This configuration permits access from 'base' to all UML machines using SSH independently of the packet filtering configuration at 'fw'.

As an additional consideration, please note that the SNAT configuration in 'fw' described above is necessary for responses to outgoing connections to the Internet originating from the internal or perimeter networks to come back through 'fw'. Otherwise they would be routed directly from 'base' to the UML machine through 'tap1' or 'tap2' without traversing 'fw'.

File Information

Back to the Top

Virtual Machine

Back to the Top


Back to the Top


Back to the Top


Back to the Top