GNS3 v2.0.0 supports multiple clients connecting to the same GNS3 server. We’ll use this feature to create a centrally managed solution that fits even for remote workers accessing the virtual lab through slow WAN links.

Background

Before going into the details, let’s have a look at how GNS3 is built up. It has two major components, the GUI and the server. Obviously the GUI component does what a GUI has to do; the more interesting part is the server.

The server, among many other things, acts as a glue between the virtual nodes running on different virtualization platforms. It can create links between a Cisco IOU router and an F5 load balancer running on Qemu, a Linux server on VirtualBox and a Dynamips emulated 3725 router, a FortiGate firewall on Qemu with a FortiAuthenticator on VMware, or even all of these together in a single topology.

To ease the users' job, GNS3 provides a preconfigured VM called the GNS3 VM. All you need to do is connecting the GUI with the GNS3 VM, and everything else is done automatically. This VM can be placed to a remote server, which can provide more resources than an average PC or laptop.

Concept

It naturally comes from the above that we can build a virtual lab for a whole team from a server with adequate resources. There’s one catch though: exporting and importing images and topologies means moving data and, depending on the topology size and the options, this can even mean gigabytes. Not something for slow WAN links…

To solve this problem, we’ll place a Windows terminal server on the same ESXi host where the GNS3 VM will be hosted, and connect the two using a dedicated vSwitch and port group:

Other benefits of this solution:

• Business continuity: If someone messes up something, it won’t spread to your production network.
• Ease of use: Users' GNS3 settings are created automatically.
• Security: You won’t see random MAC and IP addresses appear on your network.
• Multiple users can work on the same project at the same time.
• Single point of management: Neither you have to manage multiple GNS3 installations nor your users have to manage their own.

If your security policy requires a firewall to be in place between your production network and your lab environment (it’s recommended), you should allow these connections:

Installing the components

I won’t describe the details of each step as multiple documents are available on them:

• Install and configure ESXi, optionally integrate it with vCenter.
• Import the GNS3 VM.
• Install Windows Server, add a new vNIC to the same port group that you created for the GNS3 VM, and enable Terminal Services. Note: I used 2012 R2 for testing.

This is how the new vSwitch and the Windows Server should look like:

Configuring GNS3 for the first time

When you start GNS3 for the first time (logged in as Administrator), select “Run everything on a remote server”:

Then add the IP address of the GNS3 2nd vNIC that’s connected to the same port group where the Windows server’s new vNIC:

After adding the remote server, you can start creating or importing appliances.

Preconfiguring GNS3 for the users Since the settings for GNS3 are stored under each users home folder, every new user would have to add the remote server using the steps above. To ease their job, we can automate this process by doing to following steps.

1. Copy the GNS3 setting to the Default user

When GNS3 was started and the remote server was added, the settings were saved in the C:\Users\Administrator\AppData\Roaming\GNS3\ folder. Copy the whole folder to C:\Users\Default\AppData\Roaming\. The Default user acts as a skeleton (/etc/skel in Linuxland); when a new user logs in, this Default user contains the new users default settings.

Also create an empty file called is_skel in the C:\Users\Default\AppData\Roaming\GNS3 directory. This will be needed later.

2. Remove admin-specific settings

The GNS3 server’s ini file has some properties that point to folders owned by the Administrator. Remove these (marked with red below):

[Server]
images_path = C:\Users\Administrator\GNS3\images
    symbols_path = C:\Users\Administrator\GNS3\symbols
ubridge_path = C:\Program Files\GNS3\ubridge.EXE
password =
path = C:\Program Files\GNS3\gns3server.EXE
port = 8000
configs_path = C:\Users\Administrator\GNS3\configs
protocol = http
allow_console_from_anywhere = False
host = 192.168.100.10
udp_start_port_range = 10000
projects_path = C:\Users\Administrator\GNS3\projects
udp_end_port_range = 20000
auth = False
additional_images_paths =
console_end_port_range = 10000
report_errors = True
auto_start = False
user =
console_start_port_range = 5000

3. Create a logon script that adds user-specific settings

Download this file and store it in C:\Windows\System32\GroupPolicy\User\Scripts\Logon. Open the Local Group Policy Editor (gpedit.msc), and add the newly created script:

Important: Starting from Server 2012 R2 and Windows 8.1, logon scripts are run 5 minutes after a user logs in. If you want to change this behavior, read this article.

4. Create a user

Add new users the regular way, and include them in the “Remote Desktop Users” group (alternatively you can add the Users group to the RDP users, this way you allow everyone and don’t have to add them manually). Their pre-configured GNS3 environment is waiting for them. You can also set up a central project repository by creating topologies and exporting them to a shared folder. This way every user can import the projects and work in them by their own.