UPDATE (1 Dec 2017): This post utilized Fedora 25. There are some issues in GNS3 that are fixed in version 2.1 which is available on Fedora 26. I would recommend using this guide, but installing Fedora 26. There is also an issue with dynamips on Fedora 26, and I wrote a blog post on how to fix the issue here.
A home lab can be one of the most important tools for a network engineer. It can be used to study for certifications, test designs or ideas, and learn new technologies. In years past most network engineer’s home labs would consist of physical routers, switches, and firewalls. With the exponential growth of virtualization, a network engineer’s home lab can be converted into a single physical server that costs far less than having the physical equipment. This blog post will detail the home lab setup that I have created for my own personal use. Most of my blog posts will be using this setup, so if you are interested in recreating what I have done, this blog post will run through all the steps to set up your own home server, or at least show you the tools that I am working with. This is just the basic setup, and any pieces of software or configuration that I add-on will be documented in later blog posts.
The basic goal of the home lab was to be able to run GNS3 for network device virtualization, and also run the KVM hypervisor in order to create virtual machines. I chose KVM as my hypervisor (over VMWare’s ESXi) because I want to learn more Linux and become more proficient on the operating system. The hardware that I used was actually purchased in January 2015 and was used as my primary desktop until I decided to convert it into the home lab. While you can buy small business grade servers, good desktop quality hardware will work just fine. Below are the basic specs of my setup:
- Intel Core i5 4690-S
- 32 GB RAM
- 256 GB SSD
When running the KVM hypervisor, your processor needs to support virtualization extensions. On Intel CPUs this is called “VT-x” and on AMD CPUs it is called “AMD-V”. Intel and AMD have great documentation and you can easily find out if your CPU supports this technology. Intel’s product documentation has “Intel Virtualization Technology (VT-x)” listed under Advanced Technologies.
Running the KVM hypervisor is as easy as installing the Linux distribution of your choice, much like running Hyper-V is done through a Windows Server install. I chose Fedora as the Linux distribution of choice as I already had some experience with it and I have worked with production Red Hat Enterprise Linux servers. Additionally, Fedora is used by Red Hat to test new features that might eventually make their way into the stable RHEL release. This means that Fedora most likely has the most cutting edge technology available, but can come at the price of stability. I have found Fedora to be stable enough for what I need, and I also like the ability to test out the latest and greatest. If you are looking for something more stable, I would suggest either CentOS if you would like a Red Hat derivative or Ubuntu (a Debian derivative). Ubuntu is one of the most popular Linux distributions, so if you are new to Linux it is a solid OS with a ton of community support. Additionally, any of these distributions can be run from a Live CD so that you can test drive them before you actually install them. That covers the ideas and reasoning behind the home lab setup, so let’s get into the setup!
This tutorial will run through the following tasks: Install Fedora Server, the XFCE desktop environment (GUI), Google’s Chrome browser, GNS3, and X11 forwarding that will allow you to remotely run GUI applications. The first step is to obtain installation media for Fedora. Head over to the Fedora Server download page. I chose the Netinstall image located on the right side of the page. The netinstall is a minimal initial download, because when you actually install the OS it will pull down the latest packages for installation. This allows you to have the most up to date system after initial install. You will also need to download Fedora Media Writer to create a bootable USB drive for the install. Fedora Media Writer is available for both Windows and macOS. When you launch the application after installation, you should see the following screen:
Because we have already downloaded our boot image, select “Custom image” from the menu. Browse to the directory where you downloaded the netinstall ISO image. Once you select the file, you will then choose which device you want use as the USB boot device:
Choose the correct USB device and then select “Write to disk.” Because we downloaded the netinstall image, the write should not take very long. Once complete, you will be good to start your Fedora installation. Keep the USB device plugged into your computer and then restart. You will need to change the boot order for your computer in order for it to boot into the USB device. There are two ways to accomplish this: go into the BIOS/UEFI setup and change the boot order, or some motherboards have the ability to go right to a boot menu to pick which device to boot from. When you first boot your comuter, a menu should appear, and the usual keys to press are DEL, F8, F10, or F12 for the BIOS/UEFI or boot device menu. This menu can sometimes disappear quickly so you may need to reboot again to catch it. Either way you will need to move the USB device to the top of the boot list so that it boots first. If done correctly you should be greeted with the following screen:
You can either test the media to ensure that the image is good, or you can just proceed to installing Fedora 25. At the start of installation, you will be asked which language you will want to run the installation in:
Select whichever language you are comfortable with and click on Continue. The next screen will be the main installation view:
From this view you can customize your install of Fedora Server. The installation is broken up into three parts: Localization, Software, and System. Localization allows you to select your keyboard layout, Language Support, and Time/Date. The installer is pretty good at detecting your keyboard layout and the language is set from your selection when the installer first opened. Open Time & Date to select your timezone, and whether or not you want to use NTP to synchronize time. When you click on one of these options to begin customization, there will be a blue “Done” button at the top left-hand corner of the screen that will save your selection and return you to the installation summary.
Installation source allows you to change where you will be getting your files for installation from. If you used the netinstall image it will default to the closest mirror that it detects. I would only change this if you are aware of a mirror that you know is faster than the closest one, but in most cases the closest one will be the fastest.
Software Selection is where you can pick what software will be installed. Below is a screenshot of what it looks like:
This is your home lab so you can install whichever packages you want. Even though you downloaded the server netinstall image, you can see from your choices that you can install Fedora Workstation, Cloud Server, or a wide variety of other options. The left hand side will be the base installation, and the right hand side will be packages that you can add to that base. For the start of my home lab I wanted to keep it as minimal as possible, so I chose “Fedora Server Edition” for the base and only checked “Headless Virtualization” for my add-ons. Once you have decided on the base install and add-ons, click the blue Done button.
The next step in the process of installation is to select the installation destination. This basically is how you are going to organize your hard drive for the install, and more specifically it is how you will partition your hard drive. There is no perfect way to partition your hard drive for Linux, and you can find endless articles/blogs online detailing the many different ways it can be done. Since this is going to be a simple home lab with only a single user, I just let the installer do the dirty work for me. Click on Installation Destination to bring up the details:
***NOTE: I ran through this tutorial on a VM to take screenshots so the Hard Drive size does not reflect the 256 GB SSD that I mentioned earlier***
The Installation Destination will show all of the local disks that were detected on the system. By default the option for “Automatically configure partitioning” is selected under “Other Storage Options.” If you click on “I will configure partitioning” you can still have it automatically partition, but you will get to see what the installer has chosen. I like this option so that I can see what is happening and I can tweak it if I feel so inclined to. After selecting “I will configure partitioning” and clicking on “Done,” you will then be brought to the manual partitioning settings.
Click on the “Click here to create them automatically” to have the installer suggest a partitioning scheme to you. Below is the scheme that was presented (this was the same as my 256 GB initial install, just with different partition sizes):
The installer chose four partitions and I will briefly explain what each is for.
- /home – This is your home directory, where all of your user files will be stored. This is equivalent to the C:\Windows\Users folder that you should be familiar with if you are a Windows user.
- /boot – This is the location where the boot loader is installed that will actually boot the system.
- / – This is the root of the filesystem and is equivalent to C:\ in Windows. Linux has a hierarchical file system with / being the top.
- swap – This is a partition that will be used for virtual memory. Think of the page file in Windows.
Again there are a multitude of ways that one can partition, but for someone just getting into Linux then this “default” should work out just fine. The only adjustment I would make is if you want to change the sizes of the “/home” and “/” partitions. I personally chose to increase the “/” partition and decrease the “/home” partition because I plan to have more data (mostly VMs and installation ISOs) stored outside of my “/home” directory and thus would fall under the “/” partition. Once finished, you can click “Done” and return to the installation summary. The last configuration before starting the actual installation is to set up your networking. If you are running DHCP on your home router and are connected via an ethernet cable then your settings should be automatically set:
If you need to specify an IP address, or need to enter other specific information for the network connection, then you can select your connection on the left side and click on “Configure” to enter your desired configuration. Click “Done” once complete and you will be ready to begin installation. On the installation summary page there will be a blue “Begin Installation” in the bottom righthand corner. Click it to begin and your screen should change to look like this:
The installation will then begin downloading and install all the packages associated with the base install and add-ons you selected earlier. While this is happening you will be required to create the root password and create a user account. The root password is the administrative password for the system. While it is possible to login to the system as root, it is best not to. This helps keep the system secure so that if it is to get compromised in some way, the account that is active at that time will not have full administrative permissions. It also prevents users from making changes to the system that could cause problems. Click on the Root Password and then enter your password, clicking “Done” when both passwords match. Next click on User Creation to create your user account.
Enter in the username you would like, followed by a password for it. Click the “Make this user administrator” check box so that this account can have administrative privileges. Clicking on the advanced button will show how Linux will make this account an administrator.
Look at the Group Membership that has been populated. This account will be added to the “wheel” group. In Linux, the wheel group is like the administrator group in Windows. The wheel group allows a user to perform “sudo.” Sudo is a command that lets a user execute a command with administrative permissions. This means that even though a Linux account may have administrative privileges, the account must request when to use those permissions. Additionally, when someone issues the sudo command, they will be prompted to enter their password.
You don’t need to make any changes on this screen. I wanted to show it so that you can understand how the account is made into an administrative account. You can click either Cancel or Save Changes, since we didn’t make any, and click Done on the Create User screen. Once back at the installation progress screen, all you have to do is wait until all packages have been installed! Once the progress bar is full, you will see a blue “Reboot” button at the bottom. Click it to reboot and boot into your new Linux installation!
Let your computer boot up and you will be greeted with the Grub boot loader. This is where you can select which operating system you want to boot.
Grub can have multiple entries, so if you were to install multiple operating systems you could list them here. With a fresh install you will see two entries. One is your Fedora install, and one is a rescue mode that you can use in the case your operating system becomes unusable. You can either click enter to boot the first entry, or wait for the timer to count down and the first entry will be booted. After the system boots you will be greeted with a login prompt:
Enter in your username and password and you should get the following prompt, but with your unique username and hostname:
Lets do a quick breakdown of the prompt. The first part is the current username, followed by the @ symbol, and then the hostname. The ~ signifies that you are in your home directory. If you change between directories, this will change to show the current folder you are in. Below I will change from my home (~) directory to the Documents folder.
[otaku@netlab ~]$ cd Documents [otaku@netlab Documents]$
Now that we have a working Linux installation, let’s go ahead and install a Desktop Environment (GUI). You don’t have to install a Desktop Environment, but I plan on sometimes opening the GNS3 GUI on this machine as well as having the availability to use it as a desktop (such as having a terminal and web browser open to troubleshoot when things aren’t going exactly as expected). To install programs on a Linux machine you have two options: compile from source code or use a package. Compiling from source code is the manual way of installing programs, and for me I only do it if the program I am trying to install does not have a package associated with my distribution. While there is nothing wrong with compiling from source, it can take much longer to install and also dependencies can be a pain. Dependencies are prerequisites to installing, such as libraries or other applications. Packages on the other hand are pre-compiled and take much less time to install. Additionally, if you use a package manager it can analyze the dependencies and ensure they are all also downloaded and installed.
Now you may be wondering how the package managers know which packages are available for download. Package managers utilize repositories which is basically the list of packages that can be downloaded from that particular repository. Upon initial install, the only repositories available will be the official Fedora repositories. These are the most trustworthy repositories. Certain applications may be found in different repositories. In order to use your package manager to install packages from other repositories, you must tell your system about them. We will cover this when we install Google Chrome.
The package type for Fedora (and other Red Hat based distros such as CentOS) is RPM packages. The current package manager for Fedora is DNF (Dandified Yum), which is the newer version of the older RPM package manager Yum. The basic syntax of DNF is “dnf [command].” Commands include install, remove, upgrade, and group. A full list can be obtained by typing “dnf –help” at the command line. Since there are a lot of parts that make up a Desktop Environment, they are not installed from a single package. Luckily, group packages have been setup so that if you want to install something like a Desktop Environment, you can tell dnf to install all the packages pertaining to a certain group. Because we are at the command line, if you simply enter “dnf group list” then all possible group packages are listed, but the terminal will automatically scroll down so you will not see the output of the beginning. In order to get some scrolling functionality, and to be able to actually see all of the options, we will utilize the “more” command as well as a command line technique known as “piping.”
Piping allows output from one command can used as input to a second command. In our case, we will feed the output of “dnf group list” – our long list of available packages – into the more command. What the more command will do is only display as much data as can fit onto the screen, and then we can hit “enter” to view more of the output. If you are using a larger monitor, all of the text may show up on the screen at once and you will not notice anything when using the “more” command. I added this in case anyone is using a smaller monitor.
To see the list of available group packages type “dnf group list | more” at the CLI.
[otaku@netlab~]$ dnf group list | more
At the top should be the list of “Available environment groups,” which contains all the group Desktop Environments. You can try out different desktops if you want. Each now has a slightly different look and feel. If you have another computer or a device such as a smartphone or tablet, then you can do some quick google searches to view images of the different desktop environments.
Now, if you remember back to when we created our user account I stated that this account does have administrative privileges, but you will need to use “sudo” before executing a command that requires elevated privileges. We were able to do “dnf group list” without elevated privileges, but that is only because we were simply listing available groups. In order to use other dnf commands, such as install, you will need to use sudo. ‘sudo dnf install “Xfce Desktop”‘ will install the Xfce desktop environment.
[otaku@netlab~]$ sudo dnf group install "Xfce Desktop"
Notice the quotes around Xfce Desktop. Because this package group contains two words, you must surround them in quotes for dnf to know that is the entire package name. If you don’t, dnf will think Xfce and Desktop are two separate packages to be installed. Enter your password and dnf should begin working to install the package group. You will get several prompts during the install. First, all the packages and dependencies will be resolved. Dnf will display these to you and you will have to enter Y in order to confirm the installation of all packages. Since this is the first time downloading software from the official repositories, once the downloads are complete you will be prompted to accept the signing key used by the distro and you will have to enter Y for this too. Having a signing key allows the system to validate packages that come from the repository. After that the installation should begin. Dnf will install and verify all the packages before completing.
Once installation is complete, there is only one thing left to do before we can use the Xfce desktop environment. The command “startx” is used to start a desktop environment. If we run that command right now, your screen should turn black, and then you will be dropped back to the command line.
Don’t worry if you can’t decipher everything on the screen. If you read through every line, you don’t see any particular errors. So what happened? Well startx worked as intended, but it didn’t know which Desktop Environment to load! There is a file named “xinitrc” that startx reads to see what Desktop Environments to load. This file is hidden in each user’s home folder. Lets see what the contents of it are. “Cat” is a program that can be used to print text from a file to view its contents. The full command we will use to view the file is “cat ~/.xinitrc”.
[otaku@netlab ~]$ cat ~/.xinitrc
Cat is the program we are going to use and ~/.xinitrc is the file we want to print the contents of. Remember ~ is our home directory so “~/” is signifying that the file is in our home directory. The “.” before the filename indicates that the file is hidden. Hidden files in Linux have “.” at the beginning of the filename. Let’s see what our xinitrc contains:
So it looks like startx is working properly, but it didn’t know which desktop environment to open because there is no xinitrc file for it to read. Almost everything in Linux works off of a configuration file, so the practice of having to modify or create a configuration file before an application will work correctly is very common. If we put “exec /usr/bin/xfce4-session” into our xinitrc file then we should be good to go. This command tells startx to execute the file /usr/bin/xfce4-session in order to start the desktop environment. One quick way to put text into a file is with the Echo command. Echo by itself will print text out to the screen. We can use Echo command in conjunction with > (replace the file) or >> (append to the file) to put text into a file. Since the file does not exist, either > or >> will work. “Echo “exec /usr/bin/xfce4-session” > ~/.xinitrc” is the full command.
[otaku@netlab ~]$ echo "exec /usr/bin/xfce4-session" > ~/.xinitrc
Before we run into starting startx, let’s check that our last command actually worked. We can press up to go through our command history until we get to the previous cat command we ran.
Run startx again, and now it should load the Xfce desktop environment. If you used a different desktop environment, then you will have to specify the required filepath for starting that desktop environment. Googling “xinitrc [DESKTOP NAME]” should provide you with the correct filepath.
The first time you start Xfce you will be asked a question about your initial setup. I would suggest “Use default config” rather than “One empty panel.” Default will look like a normal desktop already setup, whereas “One empty panel” will be completely blank and you will have to configure everything yourself. The default config will look like this:
In the top left corner you have “Applications” which is how you can browse all of your applications. They are all arranged into categories that make it easy to browse. The empty gray middle is where your running programs will be listed, much like the task bar in Windows. The right hand corner has the current user logged in, power status, network status, keyboard language (EN for english) and the current time. The icons on the desktop will show disks the system is aware of (the Linux filesystem will be listed as File System, where other disks such as if the system has multiple hard drives will be listed by volume name or the size), the Trash can, and a Home icon for your home folder. The bottom of the desktop is populated by a dock, much like macOS. The defaults are Show Desktop, Terminal, File Manager, Internet Browser, Application Finder, and your home folder. This dock can be customized to incorporate your most used applications so that you can use the dock rather than always having to search the Applications menu.
One of the main reasons for me to have the desktop is for easy web browsing. In this default installation of Xfce, only the bare minimum applications are installed, which does not include a web browser. I prefer Google Chrome, so let’s install that next.
Google Chrome cannot be found in the official Fedora repositories, so you must configure dnf to search the official google chrome repository in order to download it. The way you tell dnf about other repositories is by creating a file within /etc/yum.repos.d that ends in .repo. Dnf will search this repository before performing any functions to know all of the repositories it can use. The configuration file will contain all the information dnf needs to communicate to and pull files from the repository. Since we will be creating a configuration file with multiple lines, unlike the single line in .xinitrc, we will use a text editor to make the changes.
First open up a terminal to bring up a command line just like the one we were using prior to using Xfce. The text editor we will use is nano. I like using nano for simple files because it is very easy to use. Other text editors like vi and Emacs are much more powerful, but they also come with a steep learning curve. I do recommend learning one or the other(or another advanced , but for now using nano will be a good start into creating/editing text files from the command line.
The repository name will be google-chome, so we will need to create that file within /etc/yum.repos.d. Because this file location is part of the root filesystem, and not our home directory, our user will not have permissions to create it. We will have to use sudo in order to create the file. Enter “sudo nano /etc/yum.repos.d/google-chrome.repo” into the terminal to open the nano text editor. Specifying the filename and location now means that we don’t have to enter it in again when saving.
[otaku@netlab ~]$ sudo nano /etc/yum.repos.d/google-chrome.repo
Your terminal should now look like this:
We now need to populate the config file with the details for the Google Chrome repository. Repositories (you can do a google search for different Fedora repositories) will either give you the details of their repo or have a file that will automatically create this file for you. Creating this first one is a good way to understand the underlying parts of the dnf package manager and how repositories work. Enter following files into the text editor:
[google-chrome] name=google-chrome baseurl=http://dl.google.com/linux/chrome/rpm/stable/x86_64 enabled=1 gpgcheck=1 gpgkey=https://dl-ssl.google.com/linux/linux_signing_key.pub
Once you have entered the information in, press CONTROL and X at the same time to exit nano. You will be prompted if you want to save your changes (Press Y) and then to name the file. Because we already entered the file name when opening nano, this will already be populated. Ensure it is still etc/yum.repos.d/google-chrome.repo. If you made a mistake when first opening nano you can correct the directory/filename here. Hit enter to save the file. You can cat the file to ensure the changes were entered correctly.
[otaku@netlab ~]$ cat /etc/yum.repos.d/google-chrome.repo
If everything matches up, run “sudo dnf install google-chrome-stable”
[otaku@netlab ~]$ sudo dnf install google-chrome-stable
Hit Y at the prompts and the installation should go through without a problem. Once complete, click the Applications menu and you should now see an Internet submenu:
Now for the main application this server was built for: GNS3. Luckily for us, as of Fedora 24 the gns3 packages are now part of the official repos. Prior to this, GNS3 took a little more effort to install on a Fedora system. Simply use dnf to install the following packages: gns3-server, gns3-gui, wireshark, wireshark-qt. You can list multiple packages to install with dnf so you only have to run the command once.
[otaku@netlab ~]$ sudo dnf install gns3-server gns3-gui wireshark wireshark-qt
KVM was installed when we installed the server, so we don’t need to do anything to install that. KVM will allow us to create VMs for emulating certain systems in GNS3. Next we have to install dynamips which is used for Cisco IOS emulation. First we will use dnf to enable the repo where dynamips can be found and then install it:
[otaku@netlab ~]$ sudo dnf copr enable athmane/gns3-extra [otaku@netlab ~]$ sudo dnf install vpcs dynamips
Hit y when prompted if you want to enable the copr repository or not. This is a warning telling you that this repository is not an official Fedora repository so The Fedora Project cannot 100% guarantee the quality. These setup steps came from the official GNS3 website on how to install GNS3 on Fedora, so I feel the repository can be trusted. Once installed, I performed one last setup before launching the application.
Since I want to use this server as a GNS3 server, there will be times when I will be using another system to access the GNS3 server. For me this means running the GNS3 GUI client on my Macbook Pro, but connecting to my home lab server in order to run the actual emulated devices. With the default install on Linux, GNS3 will only run when I launch the application. What I want to do is have the GNS3 server start-up automatically without having to launch the GUI. If you noticed when we installed GNS3, there are separate applications for the server (gns3-server) and GUI (gns3-gui).
A quick google search led me here, which details how to run the server as a daemon. A daemon is a program that runs as a service. The page links to the gns3server github page, which contains a script file that will run gns3-server as a service. You can then make this daemon run at startup so you know the GNS3 server is always running. Rather than download the raw data file from github and move it to the correct location, I found the most reliable way to get the gns3 service working was to view the raw data on the github page, copy it, nano the actual file (/lib/systemd/system/gns3.service), and then paste script into nano. When I tried to download the file and then copy it to the correct location, I kept getting SELinux errors. Since I am not well versed in SELinux, I found manually creating the file worked without issue. First click here to view the raw file. Highlight the contents and copy it. Next, open your terminal up and use nano to create the gns3.service file:
[otaku@netlab ~]$ sudo nano /lib/systemd/system/gns3.service
Exit and save after pasting in the contents. Now we have to change the owner of the file to root. The “chown” commands is used to change the owner of a file.
[otaku@netlab ~]$ sudo chown root /lib/systemd/system/gns3.service
First lets enable the service. This sets the service to start at boot up. This will allow the server piece to run without having to load the GUI.
[otaku@netlab ~]$ sudo systemctl enable gns3.service
You should get some text on the screen saying that the system created some links, which are references to our gns3.service file so that the actual script doesn’t have to be loaded into multiple places. Once that is complete we can start the service using systemctl start.
[otaku@netlab ~]$ sudo systemctl start gns3.service
The error message above is what I got on my system when first trying to start the service. If you got the same error, then continue on for a fix. If you did not get an error, then you can skip over this part and resume where we run “systemctl status gns3.service” to verify it is working properly.
Looks like the service script isn’t working. Let’s see what systemctl status tells us.
Now while I am no expert, it doesn’t appear that any specific error has occurred. I can see from the output that the script calls “/usr/local/bin/gns3server” as the application for gns3. Perhaps where the script is pointing to for the GNS3-server application is incorrect? That’s my first assumption. Let’s see if it exists:
[otaku@netlab Downloads]$ ls /usr/local/bin/gns3server
Looks like the script is looking for a non-existent location. Linux has a handy utility for searching for files: find. You can specify where you would like to search, but since we don’t know exactly where it is installed we will search /, or the root of the filesystem. This will search everything. One thing to note is that since we will be searching a lot of places we won’t have access to, we will be using sudo. If not, the screen will be flooded with a lot of permission denied and it will be hard to find the actual location. When using find, you first name the directory you want to search (/ for us) and then there are many switches you can use based on what you are searching for. Since we know the name of the file we are looking for (gns3server, as named in the script), we will use the -name switch and provide the name we are looking for.
[otaku@netlab Downloads]$ sudo find / -name gns3server
So gns3server is located in /usr/bin/gns3server and not /usr/local/bin/gns3server. Let’s modify the script and see if that corrects the problem. Open up the file with nano, change the line highlighted earlier and remove the /local part, and then CONTROL+X to save and quit. Cat the file once saved to ensure the changes were correct.
[otaku@netlab ]$ sudo nano /lib/systemd/system/gns3.service
Now since we modified the script after enabling it, we will have to reload the daemon. That is just a simple systemctl daemon-restart command. If no errors pop up when starting the service, you can use systemctl status to ensure it is running.
[otaku@netlab ~]$ sudo systemctl daemon-reload [otaku@netlab ~]$ sudo systemctl start gns3.service [otaku@netlab ~]$ systemctl status gns3.service
Now we have successfully installed gns3 as a daemon, got it running, and set it to start at boot up. Next we will configure the local gns3 GUI. Because we have gns3-server running as a daemon, we will have to configure the GUI as if we are connecting to a remote server. GNS3 is located in your applications menu under Internet. When you first open it up you should get the Setup Wizard. Because we will be setting this up as a remote server connection, you can cancel out of the wizard:
If you get prompted about a newer version, click no because since we just downloaded from the official Fedora repository, we know we have the latest working version. The new version has not been tested and put on the repository yet. We first need to tell GNS3 what server will be running. Click on Edit on the top menu and then Preferences.
Once the preferences are open, click on Server on the left hand side. Uncheck the “Enable local server” box.
Next click on the Remote servers tab to bring up the remote server configuration. Click on Add.
A new window will pop up, and all you have to do is put in the IP address of your server. If you do not know, open a terminal and use the “ifconfig” command. It is like the ipconfig command in Windows. Find the IP address that matches the network of your home network.
[otaku@netlab ~]$ ifconfig
Once you enter everything, click on OK and you should now see your server configured under the Remote servers tab.
Now that you have your server setup, click on Apply and then OK. You are now ready to use GNS3 on your local server. Lets connect to it from another machine.
In order to connect to this GNS3 server from other computers on your network, we need to first check the ports being used, and then ensure we put rules in the firewall to allow connections to these ports. Since we are already in GNS3, let’s check that first. Open up the preferences in the edit menu again. Click on server on the left hand menu. If these options are grayed out, just close the preferences and open again. You should see a screen like the one below:
Port 3080 TCP should be set as default. This port is how the GNS3 GUI will connect to the server and be able to run devices such as Cisco IOS routers. The Console port range is used for when you actually console into the devices to configure them. I set it to 5000 to 5500, but you can set it any way you would like. Either way just make sure you annotate what range you entered. Hit Apply then OK to ave the settings.
Once the ports have been setup, they have to be allowed through the firewall. Firewalld is used by Fedora for the system’s firewall front end. It is a nice, easy to use interface for modifying the firewall. If you have used other firewalls or security devices, you should be familiar with security zones. Firewalld implements the same system, so when rules are added or removed you apply it to a security zone. Our first step is see what zone is active and apply to our network interface.
[otaku@netlab ~]$ firewall-cmd --get-active-zone
Firewall-cmd is the command to modify or view firewall settings, and –get-active-zone will print the active zone (FedoraServer) and let us know which interface it belongs to. Now we know that our ports (TCP 3080 and 5000-5500) need to be allowed on the FedoraServer zone. Firewalld has two ways to make changes to the firewall policy. You can either add policy to the runtime firewall, but these changes will not be added permanently. When the system or service is restarted, these configurations will be lost. To add them permanently, you first have to add them to the runtime and then to the permanent rules. Both commands are identical with the only difference being that the permanent rules contain “–permanent.” The switch we will be using is –add-port, which needs to be told both the port number(s) and protocol(tcp or udp). Below is how to addport 3080 and then the range 5000-5500.
[otaku@netlab ~]$ sudo firewall-cmd --zone=FedoraServer --add-port=3080/tcp [otaku@netlab ~]$ sudo firewall-cmd --permanent --zone=FedoraServer --add-port=3080/tcp [otaku@netlab ~]$ sudo firewall-cmd --zone=FedoraServer --add-port=5000-5500/tcp [otaku@netlab ~]$ sudo firewall-cmd --permanent --zone=FedoraServer --add-port=5000-5500/tcp
Once the rules have been added to both the runtime and permanent rule sets, we can query them by replacing –add-port with –query-port. You still have to enter the port and protocol combo. If it is allowed, you will see a yes printed on the screen. Once you have confirmed all ports are opened, restart the firewalld service to make the changes permanent.
[otaku@netlab ~]$ sudo firewall-cmd --query-port=3080/tcp [otaku@netlab ~]$ sudo systemctl restart firewalld.service
Once the firewalld service has restarted you can go query the ports again to see that they are now permanent and will survive the service or system restarting.
Next let’s connect to the server from another workstation. I will be testing with my Macbook Pro. One thing to note is that both the server and GUI have to be the same GNS3 version. Because OS X has a newer version available from the main GNS3 website, I had to go to the github page in order to find the same version. Click here to browse through the GNS3 releases. Each release has both a .dmg (macOS) and .exe (Windows) available for easy installation. Just follow normal installation instructions for these files. The GUI will look just like the one we used on Xfce, so adding a remote server will follow the exact same procedure. Follow the same procedure as earlier:
- Open Preferences
- Click on Server
- Uncheck Local Server
- Click Remote Server Tab
- Click add, entering IP for remote server.
- Click Apply and OK
You should now see the server listed on the “Servers Summary” pane in the middle right portion of the main GNS3 screen. The circle next to it will stay gray until you actually connect to it to run a device.
From our GNS3 GUI we will now add a Cisco IOS router. Note that you will have to obtain an IOS image on your own as GNS3 does not provide them. This procedure will be the same whether you are on the remote server or just using the GUI from a workstation. Open up the preferences, but this time select Cisco IOS Routers under Dynamips. Click on the New button.
The next screen is where you will detail where the new device will run. Select “Run the IOS on a remote computer” under Server type and select the appropriate server IP on the drop down.
If the server has been setup correctly, when you hit the next button you should have no issues. If the workstation is unable to access the server, you will receive an error message and will have to troubleshoot what the problem is. Since this is a very basic setup, the main things to check is that the GNS3 service is running on the server, and that the appropriate ports have been opened up on the firewall. If all went well, the next screen is where you select the IOS to use. Select New Image and then click the Browse button. A window will pop up for you to select the location of the IOS file.
Once you have selected the correct IOS file, click Next. The next two screens are for device name, platform, and memory. I usually keep these as the default so you can just click Next through those screens. The important screen for me is the third one that lets you select the interfaces.
You are creating a template for devices that you will drag and drop into your various topologies. If you load up on the interfaces now, then you don’t have to worry about manually adding them during various labs. I like to put at least 6 interfaces (each slot pictured above has 2FE which stands for 2x Fast Ethernet). Click next once you have added the interfaces you would like.
The next screen is the for the idle-pc value. The idle-pc value is essential to ensuring that your routers are not eating away excess CPU. Click on the Idle-PC Finder button until a value that is highlighted in green is shown in the text box.
Once completed, click on Finish. This will close the new IOS router wizard. You can select OK on the preferences window to close our the preferences as well. You now have an IOS router template on your remote server that you can use for topologies. Click on the Browse Router button on the top of the left hand menu and you should see your newly added device template.
Now you can begin building network topologies! Refer to the GNS Official Website for a plethora of documentation on how to use GNS3 to its full capability.
Now that the GNS3 server and remote workstation are setup, it is time for two last configurations. First, we will be installing the GUI tool virt-manager, which will give us a nice user interface to create VMs. After that we will setup X11 forwarding that will let us run GUI applications (namely virt-manager) through an SSH connection.
Installing virt-manager is simple because it is found in the official Fedora repositories. A simple “sudo dnf install virt-manager” is all you need to install the software.
[otaku@netlab ~]$ sudo dnf install virt-manager
If you are running Xfce on your server then you will now see Virtual Machine Manager in the Applications menu.
You can either open it from the application menu, or from the terminal (within the Desktop Environment) you can type “sudo virt-manager.” Sudo is required because virt-manager requires elevated privileges.
Now that we have virt-manager installed, lets enable X11 forwarding so that we can run this GUI application from an SSH session. On the server, all you have to do is ensure that X11 forwarding is enabled in the SSH configuration file. This is done by having a line in the configuration that reads “X11Forwarding Yes.” The configuration file is found at /etc/ssh/sshd_config. Before we open the file, let’s use a very powerful command line tool that lets us search within files or directories: grep. Grep works by supplying the regular expression to be searched (X11Forwarding in this case) and the file/directory to search for it (/etc/ssh/sshd_config).
[otaku@netlab ~]$ sudo grep X11Forwarding /etc/ssh/sshd_config
If grep finds the line, then it means that X11 forwarding is already enable on the server-side. If grep finds either “X11Forwarding no” or “#X11Forwarding yes” then you need to open the config file with nano and change that line to read “X11Forwarding yes” in order to enable it. A “#” character at the beginning of the line blocks SSH from applying that line of the configuration. If you do have to change the sshd_config file, then you will need to restart the ssh service afterwards.
[otaku@netlab ~]$ sudo systemctl restart sshd.service
On the client side, you will need to install software that can handle the forwarding of X11 packets. For macOS this software is called XQuartz. Follow the link to the homepage for XQuartz that has the .dmg file. Once you install XQuartz, you can test it out by opening up a terminal and connecting to the server using “ssh -X user@server_ip” replacing user with the username and server_ip for your server’s IP address. Now since I am using X11 Forwarding to open virt-manager, and virt-manager requires sudo privileges, I had to make a small tweak in order to be able to do it. It looks like there can be problems when connecting via SSH as one user but then trying to run files as another user or use sudo. I found this Unix Stack Exchange post that had the fix for it. You must modify your user’s bash profile (found at ~/.bash_profile) and add a new line containing “export XAUTHORITY=$HOME/.Xauthority” in order to get it to work. Below is an example of me connecting to my home server and then running virt-manager:
On Windows it seems you have multiple options, with one popular one being Xming. I do not have any Windows clients currently, so I was not able to test using one. This YouTube video shows how to install Xming and use Putty to SSH and run GUI applications over it.
After following this tutorial, you should having a working Linux system with a Desktop Environment, KVM, GNS3, and Google Chrome installed. This is a great base to start your home lab. Whether you are just starting out on your career, or have been working for 10+ years, a home lab is a great tool to have at your disposal. If you have any problems with this tutorial, please leave a comment below and I will do my best to either update this post or help point you in the right direction to fix your issue.