Install GNS3 on Fedora 45 / 44

Installing GNS3 on Fedora is now one dnf command, and it does more than older guides expect. The gns3-server package ships its own systemd unit and a gns3 system user, uBridge arrives with its capabilities set, and the weak dependencies bring in QEMU/KVM and Fedora’s Docker engine. Start the packaged gns3.service as shipped and it listens on every interface with no password. From another LAN host, a plain curl with no credentials returned its full compute list, which means the whole API is open.

Original content from computingforgeeks.com - post 4647

We install the GUI on Workstation and the server on a headless host, build Dynamips and VPCS, fix the first-launch console error, and lock the API and consoles down. We tested in October 2026 on a Fedora 45 Workstation, a Fedora 45 server and a Fedora 44 server with GNS3 2.2.61. Labs used VPCS, a switch and an Alpine Docker node; we checked KVM detection but booted no QEMU or IOS image.

What Fedora 45 and 44 ship for GNS3

Both releases carry the same GNS3 build, so the steps below are identical on 45 and 44. What differs is the stack around it, and the size of the install. These are the versions we installed, read from rpm -q and the dnf transaction summaries on fresh servers; the gns3-server package in Fedora is where the unit, the service user and the weak dependencies are defined:

Component	Fedora 45	Fedora 44
gns3-gui, gns3-server	2.2.61 (fedora repo)	2.2.61 (updates repo)
ubridge	1.2.3, capabilities preset (1.3.0 queued as an update)	1.2.3, capabilities preset
Python	3.15.0	3.14.8
qemu-kvm	11.1.2	10.2.2
moby-engine (weak dependency)	29.7.2	29.8.2
dnf install gns3-server on a server	346 packages, 302 MiB	381 packages, 311 MiB
systemd unit and service user	gns3.service, gns3	gns3.service, gns3
Dynamips, VPCS	not packaged, build 0.2.25 and 0.8.5	not packaged, build 0.2.25 and 0.8.5

Three rows change how you install it. The capabilities on /usr/bin/ubridge mean the setcap step that older Fedora guides tell you to run is no longer needed, and running it again does nothing useful. The package count is mostly QEMU and Docker arriving as weak dependencies, which is what you want on a lab box but a surprise on a small VM. And the packaged service user means you should not create your own gns3 account or write your own unit: both already exist, and a hand-made useradd gns3 fails because the name is taken.

Pick the GUI or the server install

GNS3 is two programs, the GUI where you draw topologies and the server that runs the emulated devices. Fedora packages them separately, so the install depends on where the lab runs:

• Fedora Workstation laptop: gns3-gui plus gns3-server
• Headless server or shared lab VM: gns3-server and gns3.service
• Both: the service on the lab host, the GUI pointed at it

On a Workstation the GUI starts its own local server as your user, bound to localhost with a generated password, so the API is not reachable from the network and there is no service to manage. A shared host is different: the packaged service has to be secured before you open the firewall, which is most of the work in the server sections below. If you run both, the GUI on your workstation logs in to the lab host with the user and password you set there.

Size the host for the images, not for GNS3. The server itself is light and VPCS nodes are nearly free, while every QEMU appliance needs its own RAM (512 MB for small router images, several GB for full vendor appliances). Our test machines had 4 vCPU and 8 GB on Fedora 45 and 2 vCPU and 4 GB on Fedora 44, which is a floor for VPCS and Docker labs, not a target for multi-vendor topologies. If Fedora itself runs inside Proxmox, VMware or another hypervisor, give the VM the host CPU type so KVM is available to QEMU nodes. On ours the server reported {'kvm': ['x86_64', 'i386']} for its QEMU capabilities.

Update Fedora first

Bring the system current before installing anything. The Workstation VM we cloned for this guide was 436 packages behind, including its Python, and GNS3 runs on the system Python, so an old interpreter would have shown up in every log line. Upgrade first:

sudo dnf upgrade --refresh -y

If the upgrade installed a new kernel, reboot before you continue, so the lab runs on the kernel you will keep using:

sudo systemctl reboot

New to dnf5 syntax? The DNF5 cheat sheet for Fedora covers the commands this guide uses, including repoquery and config-manager.

Install GNS3 from the Fedora repositories

On a Workstation install both packages. The desktop libraries are already there, so this pulled only 78 packages and 142 MiB on our Fedora 45 Workstation:

sudo dnf install -y gns3-gui gns3-server

On a headless server install only the server package. Expect a long transaction, because the full qemu-kvm stack brings its GTK and SPICE display modules, and those pull GTK, GStreamer and PipeWire even with no desktop around them:

sudo dnf install -y gns3-server

Fedora 45 summarised the server transaction below, and Fedora 44 came to 381 packages and 311 MiB for the same command:

Transaction Summary:
 Installing:       346 packages

Total size of inbound packages is 302 MiB. Need to download 302 MiB.

Most of that comes from the package’s weak dependencies. They give the server its QEMU and Docker backends, so keep them unless you know you will only ever run VPCS and Dynamips. List them with rpm.

rpm -q --recommends gns3-server

The list names the Docker CLI and QEMU directly.

busybox
docker
qemu-kvm
swtpm
util-linux-script

Confirm the server version, the uBridge version and the capabilities Fedora set on the uBridge binary:

gns3server --version
ubridge -v | head -1
getcap /usr/bin/ubridge

Fedora 45 and 44 returned the same three lines:

2.2.61
ubridge version 1.2.3
/usr/bin/ubridge cap_net_admin,cap_net_raw=ep

If getcap prints nothing on your machine, the binary was replaced or copied without its attributes, and GNS3 refuses nodes that need privileged uBridge access (Docker, Cloud, NAT and TAP links) with uBridge requires root access or the capability to interact with network adapters. Plain UDP links such as VPCS to VPCS keep working, which can hide the problem until your first Docker node. Reinstalling the package restores the capabilities: sudo dnf reinstall -y ubridge.

Build Dynamips and VPCS

Neither emulator is packaged for Fedora 45 or 44, so build both from GNS3’s GitHub repositories. Dynamips runs the classic Cisco 7200, 3600 and 2600 IOS images, and VPCS is the lightweight PC node most topologies use as end hosts. Install the compiler and the two libraries Dynamips links against:

sudo dnf install -y git gcc make cmake elfutils-libelf-devel libpcap-devel

Build from the latest release tag rather than the default branch, so you get the code GNS3 actually released. The first line asks the GitHub API for the current tag, which keeps these commands correct after the next release:

DYN_VER=$(curl -s https://api.github.com/repos/GNS3/dynamips/releases/latest | grep -Po '"tag_name": "\K[^"]+')
echo "$DYN_VER"
git -c advice.detachedHead=false clone --depth=1 --branch "$DYN_VER" https://github.com/GNS3/dynamips.git ~/src/dynamips
cmake -S ~/src/dynamips -B ~/src/dynamips/build
make -C ~/src/dynamips/build -j"$(nproc)"
sudo make -C ~/src/dynamips/build install

Git prints warning: refs/tags/v0.2.25 ... is not a commit! during the clone because the tag is annotated. It is harmless, and the checkout lands on the tagged release. The binary installs to /usr/local/bin, which systemd’s default path already includes, so the packaged service finds it without extra configuration. Run it with no arguments to see its banner:

dynamips 2>&1 | head -3

It complains about the missing image and names the version it was built from.

Please specify an IOS image filename
Cisco Router Simulation Platform (version 0.2.25-amd64/Linux stable)
Copyright (c) 2005-2011 Christophe Fillot.

VPCS now has a top-level Makefile with an install target, so you no longer need the old src/mk.sh 64 run followed by a manual install. Its make install also grants cap_net_admin to the binary, which is what VPCS needs for TAP mode:

VPCS_VER=$(curl -s https://api.github.com/repos/GNS3/vpcs/releases/latest | grep -Po '"tag_name": "\K[^"]+')
git -c advice.detachedHead=false clone --depth=1 --branch "$VPCS_VER" https://github.com/GNS3/vpcs.git ~/src/vpcs
make -C ~/src/vpcs
sudo make -C ~/src/vpcs install

Check the version and the capability it set.

vpcs -v | sed -n 2p
getcap /usr/local/bin/vpcs

Both builds behaved the same on Fedora 45 and 44:

Welcome to Virtual PC Simulator, version 0.8.5
/usr/local/bin/vpcs cap_net_admin=ep

Keep the ~/src checkouts. When a new release lands, the same commands with a fresh tag rebuild over the old binaries, and the uninstall section at the end removes exactly what make install placed.

Launch the GNS3 GUI on Fedora Workstation

Start GNS3 from the Activities overview or run gns3 in a terminal. On first launch the Setup Wizard asks where to run appliances. On a single machine keep Run appliances on my local computer, which is the default on Linux:

The GUI then starts its own server as your user and writes its settings to ~/.config/GNS3/2.2/gns3_server.conf. Read it once, because it shows how the GUI’s server differs from the packaged service:

grep -E "^(path|host|port|auth|user) " ~/.config/GNS3/2.2/gns3_server.conf

On our Workstation it bound to localhost and turned authentication on with a generated password:

path = /usr/bin/gns3server
host = localhost
port = 3080
auth = True
user = admin

That matters on Fedora Workstation, whose FedoraWorkstation firewall zone opens every port from 1025 to 65535: an API on localhost never sees that traffic. One gap remains. The VPCS processes behind the consoles listen on all interfaces (ports 5001 and 5003 in our lab), and from another machine on the LAN a TCP connection to them opened. VPCS sent nothing back, because GNS3’s own console proxy already holds the single session each VPCS serves, but on a network you don’t trust, move the interface to a stricter firewalld zone.

The New Project dialog comes next. Give the project a name and click OK; GNS3 stores it under ~/GNS3/projects:

The console pane at the bottom names the stack the GUI runs on, so it is the quickest way to confirm you are on the Fedora build and its system Python. Ours read Running GNS3 version 2.2.61 on Linux (64-bit) with Python 3.15.0 Qt 6.11.2 and PyQt 6.11.0 on Fedora 45.

Build a two-PC lab and test it

Two VPCS nodes on one cable exercise the whole stack: the GUI, the server, VPCS and the uBridge link between them. In the GUI:

1. Click Browse End Devices (the monitor icon) in the left toolbar.
2. Drag two VPCS nodes onto the canvas. GNS3 names them PC1 and PC2.
3. Click Add a link (the cable icon), then connect Ethernet0 on PC1 to Ethernet0 on PC2.
4. Click the green Start/Resume all nodes button in the top toolbar.

We created our nodes and the link through the server’s REST API, which is what the GUI calls when you drag and connect, and the GUI drew the same topology. Green link ends and green dots in the Topology Summary mean both nodes are running:

Now open a console on the nodes with the Console connect to all nodes button (the >_ icon). On a stock Fedora Workstation that click fails, and the next section explains why.

Fix the console: xterm is not installed

GNS3 opens node consoles with an external terminal, and on Linux distributions other than Debian, Ubuntu and Mint its default is xterm. Fedora Workstation ships Ptyxis and no xterm, so the first console click produces this pair of errors, one per node:

GNS3 already has a preset for the Fedora terminal. Open Edit > Preferences (Ctrl+Shift+P), go to General > Console applications, click Edit and choose Ptyxis from the predefined commands. The command field fills in with ptyxis --tab --title="{name}" -- telnet {host} {port}:

Click OK twice and the setting is saved to ~/.config/GNS3/2.2/gns3_gui.conf. The same dialog has presets for GNOME Terminal, Konsole, kitty and others if you run a different terminal, and the telnet client the command needs is already installed as a gns3-gui dependency.

With the console fixed, give each node an address. Type these in the PC2 tab, then the PC1 tab with 10.0.0.1/24, and run save on both:

ip 10.0.0.2/24
save

Do not skip save. On the headless server we restarted gns3.service after changing its groups, and PC1, which had never been saved, came back with no address while PC2 kept its own. A packet capture on the link then showed echo requests leaving from 0.0.0.0 and no replies, which looks like a broken link but is only a forgotten save. Then ping PC2 from the PC1 tab:

ping 10.0.0.2 -c 4

Four replies under a millisecond mean the whole local stack works:

If the console opens but a node shows VPCS> with no reply to the ping, run show ip on both ends first. An address of 0.0.0.0/0 is the unsaved-config case above, not a uBridge problem.

Run GNS3 as a headless server

For a shared lab host, use the unit Fedora ships instead of writing your own. It runs gns3server as the gns3 user with /var/lib/gns3 as its home, so projects, images and configs all live under that directory:

systemctl cat gns3.service

Note what the unit does not set. There is no host, no port and no credential anywhere in it.

# /usr/lib/systemd/system/gns3.service
[Unit]
Description=GNS3 server

[Service]
Type=simple
Environment=statedir=/var/lib/gns3
ExecStart=/usr/bin/gns3server
Restart=on-abort
User=gns3
Group=gns3
TimeoutSec=300

[Install]
WantedBy=multi-user.target

Started as shipped, the server finds no config file and falls back to its built-in defaults, which bind every interface with authentication off. The journal says so in two lines:

Oct 16 09:45:34 f45-gns3 gns3server[6963]: No configuration file could be found or read
Oct 16 09:45:34 f45-gns3 gns3server[6963]: 2026-10-16 09:45:34 INFO web_server.py:349 Starting server on 0.0.0.0:3080

On our Fedora 45 cloud server there was no firewalld at all, and from our admin machine on the same LAN a plain curl http://10.0.1.20:3080/v2/computes returned the full compute list, its capabilities and its load with no credentials. Anyone who can reach that port can create nodes, and with Docker enabled later in this guide, start containers. So write the config before you enable the service. Create the directory and an empty file owned by gns3 with mode 600, since it will hold a password:

sudo install -d -o gns3 -g gns3 /var/lib/gns3/.config/GNS3/2.2
sudo install -o gns3 -g gns3 -m 600 /dev/null /var/lib/gns3/.config/GNS3/2.2/gns3_server.conf

Generate a password, print it once so you can store it in your password manager, and write the config in one command. Pick your own user name in place of admin if you prefer:

GNS3_PASS=$(openssl rand -base64 18 | tr -d '/+=')
echo "$GNS3_PASS"
printf "%s\n" "[Server]" "host = 0.0.0.0" "port = 3080" "auth = True" "user = admin" "password = $GNS3_PASS" | sudo tee /var/lib/gns3/.config/GNS3/2.2/gns3_server.conf >/dev/null

Because the file already exists, tee keeps its owner and mode. Enable the service and check that it loaded the file:

sudo systemctl enable --now gns3
sudo journalctl -u gns3 -o cat --no-pager | grep -E "Config file|authentication|Starting server"

All three lines must appear. If you see No configuration file could be found or read instead, the path or the ownership is wrong:

2026-10-16 09:47:12 INFO run.py:222 Config file /var/lib/gns3/.config/GNS3/2.2/gns3_server.conf loaded
2026-10-16 09:47:12 INFO run.py:235 HTTP authentication is enabled with username 'admin'
2026-10-16 09:47:12 INFO web_server.py:349 Starting server on 0.0.0.0:3080

A warning that the server Cannot connect to compute 'local' right after startup is a race between the controller and the web server inside the same process. It retries after five seconds, and the next journal line reads Connected to compute 'local'. Test the password on the server itself first, in the same shell where you set GNS3_PASS, because the firewall is not open yet. A request without credentials should be refused and one with them accepted:

curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:3080/v2/version
curl -s -o /dev/null -w "%{http_code}\n" -u "admin:$GNS3_PASS" http://127.0.0.1:3080/v2/version

Fedora 45 answered 401 and then 200. Fedora 44 refused the unauthenticated request the same way, and our authenticated lab against it ran normally:

401
200

To drive this server from a GUI on another machine, the GUI’s Edit > Preferences > Server page takes the remote address and port 3080, and with Auth ticked, the same user and password. We tested remote access with curl and the REST API rather than through a remote GUI, and remote clients only get through once the firewall rules below are in place.

Open the firewall without exposing consoles

A remote GUI needs the API port, and it needs the console ports too, because the GUI’s terminal connects to each node’s console directly over telnet. Those consoles are not covered by the password you just set. With 5000-10000/tcp open to the network, we connected to port 5000 from that admin machine with nc and landed straight at a VPCS> prompt with no credentials asked. On a router image that would be its command line.

Fedora Server runs firewalld by default; the cloud image we started from did not, so we installed it first with sudo dnf install -y firewalld and sudo systemctl enable --now firewalld. Open the API port to everyone who needs it, and the console range only to the machine your GUI runs on (our admin machine, 10.0.1.10 here):

sudo firewall-cmd --permanent --add-port=3080/tcp
sudo firewall-cmd --permanent --add-rich-rule="rule family=ipv4 source address=10.0.1.10/32 port port=5000-10000 protocol=tcp accept"
sudo firewall-cmd --reload

List the result to confirm both rules took.

sudo firewall-cmd --list-ports
sudo firewall-cmd --list-rich-rules

The port and the source-limited rule both show up, while the zone’s services (ssh, mdns and dhcpv6-client on our server) stay as they were:

3080/tcp
rule family="ipv4" source address="10.0.1.10/32" port port="5000-10000" protocol="tcp" accept

From the allowed admin machine the console still answered with VPCS>. From a third host on the same LAN the console connect failed with No route to host, which is firewalld’s reject, while the API on 3080 still answered 401 without credentials. Use a subnet in the rule instead of a /32 if several people share the lab. The API itself uses HTTP basic auth over plain HTTP, and once Docker is enabled that password is as good as root, so on any network you don’t trust restrict 3080 by source the same way, or reach it through an SSH tunnel or VPN instead of opening it. The firewalld guide for Fedora covers zones and rich rules in more depth.

Repeat the password check from the machine you will run the GUI on, now that 3080 is open. Paste the password in place of $GNS3_PASS if you set it only on the server:

curl -s -o /dev/null -w "%{http_code}\n" http://10.0.1.20:3080/v2/version
curl -s -o /dev/null -w "%{http_code}\n" -u "admin:$GNS3_PASS" http://10.0.1.20:3080/v2/version

From our admin machine the first request got 401 and the second 200, the same answers as on the server itself:

401
200

000 means the firewall still blocks 3080; 401 on both lines means the password you pasted does not match the config file.

Running the packaged service on a Workstation leaves the API itself open, because the firewall will not protect you by default. The FedoraWorkstation zone already allows 1025 to 65535, so a server bound to 0.0.0.0 is reachable from the LAN the moment it starts. Set host = 127.0.0.1 in its config there, or move the interface to a stricter zone.

Add Docker containers as nodes

GNS3 can drop Docker containers into a topology as hosts, and on Fedora you already have the engine: moby-engine came in through docker-cli, which gns3-server recommends. It is not running yet, and until it is, adding a Docker node fails with this error:

Docker has returned an error: Cannot connect to unix socket /var/run/docker.sock ssl:default [No such file or directory]

Start the daemon and enable it at boot. Installing moby-engine as a dependency does not enable it, so the socket only appears after this.

sudo systemctl enable --now docker

The error then changes to [Permission denied], because the socket is srw-rw----. 1 root docker and the gns3 user is not in that group. Add it and restart the service so the new group applies:

sudo usermod -aG docker gns3
sudo systemctl restart gns3

Membership in docker is effectively root on the host, so treat the GNS3 password as a root password from here on. With the GUI’s local server on a Workstation, the server runs as your own account, so add yourself instead (sudo usermod -aG docker "$USER") and log out and back in. We added an alpine:latest node through the API to a switch shared with PC1 and PC2; GNS3 pulled the image, started the container and gave it a telnet console. In the GUI, create the template first under Edit > Preferences > Docker > Docker containers > New, then drag it onto the canvas. From the container’s console:

ip addr add 10.0.0.3/24 dev eth0
ip link set eth0 up
ping -c 3 10.0.0.1

The container reached the VPCS node through the GNS3 switch.

PING 10.0.0.1 (10.0.0.1): 56 data bytes
64 bytes from 10.0.0.1: seq=0 ttl=64 time=0.359 ms
64 bytes from 10.0.0.1: seq=1 ttl=64 time=0.210 ms
64 bytes from 10.0.0.1: seq=2 ttl=64 time=0.213 ms

--- 10.0.0.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.210/0.260/0.359 ms

SELinux stayed enforcing, and ausearch -m avc -ts boot on the server found no denials. Older guides, including the previous version of this one, tell you to add Docker’s own docker-ce repository instead. On a machine that already has gns3-server, that now fails: Fedora’s docker-cli and Docker’s docker-ce-cli conflict, and dnf refuses the transaction:

  - installed package docker-cli-29.8.2-2.fc44.x86_64 conflicts with docker-ce-cli provided by docker-ce-cli-1:29.9.1-1.fc44.x86_64 from docker-ce-stable
  - package docker-cli-29.8.2-2.fc44.x86_64 from updates conflicts with docker-ce-cli provided by docker-ce-cli-1:29.9.1-1.fc44.x86_64 from docker-ce-stable
You can try to add to command line:
  --allowerasing to allow removing of installed packages to resolve problems
  --skip-broken to skip uninstallable packages

We’d stay on moby-engine for a GNS3 host: it is what the package expects, it updates with the rest of Fedora, and GNS3 only needs the Docker socket. If the machine also runs other workloads tied to Docker CE, follow the Docker on Fedora guide and plan the swap there rather than forcing it with --allowerasing mid-lab.

Troubleshoot GNS3 on Fedora

These are the errors we hit or reproduced while testing, in the order a new install tends to meet them. Most headings are the exact text GNS3, Docker or the shell printed, so you can search this page for the message on your screen.

Could not start Telnet console with command ‘xterm …’: [Errno 2] No such file or directory: ‘xterm’

The GUI’s default console command is xterm, which Fedora Workstation does not install. Switch the console command to the Ptyxis preset under Edit > Preferences > General > Console applications, as shown earlier, or to the preset for whichever terminal you use.

Another GNS3 GUI is already running. Continue?

We got this dialog after the GUI was killed rather than closed, because it left its lock behind. If no other GNS3 window is open on your desktop, answer Yes and the GUI starts normally and reconnects to its local server. If one is open, answer No and use that window, since two GUIs editing the same project fight over it.

Docker has returned an error: Cannot connect to unix socket /var/run/docker.sock ssl:default [Permission denied]

The daemon is running but the account that runs the GNS3 server is not in the docker group. That is gns3 for the packaged service and your own user for the GUI’s local server. Add the right account to the group and restart the service, or log out and back in for your own user. [No such file or directory] in the same message means the daemon itself is stopped.

VPCS ping times out after a restart

Run show ip on the node. If it reads IP/MASK : 0.0.0.0/0, the address was set but never saved, and every restart of the node or the server wipes it. Set it again and run save. A capture on the link shows the symptom clearly: echo requests from 0.0.0.0 and nothing coming back.

useradd: user ‘gns3’ already exists

This comes from guides that create a service account by hand. Fedora’s gns3-server package creates gns3 through /usr/lib/sysusers.d/gns3-server.conf and ships gns3.service, so delete any custom /etc/systemd/system/gns3-server.service you copied from elsewhere and use the packaged unit.

Remove GNS3

Removing the packages also removes their weak dependencies, which came to 378 packages on Fedora 44. Read the transaction before you confirm it if this machine runs containers or VMs for anything other than GNS3, because the list included the Docker engine and QEMU:

sudo systemctl disable --now gns3
sudo dnf remove gns3-gui gns3-server

Three things survive dnf remove:

• the gns3 user and group
• /var/lib/gns3, kept because of the projects inside it
• Dynamips and VPCS under /usr/local

On a server without the GUI, dnf prints No packages to remove for argument: gns3-gui and carries on with the rest. CMake recorded every file Dynamips installed in install_manifest.txt, so feed that list to rm first, then remove VPCS:

sudo xargs rm -f < ~/src/dynamips/build/install_manifest.txt
sudo rmdir /usr/local/share/doc/dynamips
sudo rm -f /usr/local/bin/vpcs /usr/local/share/man/man1/vpcs.1
rm -rf ~/src/dynamips ~/src/vpcs

Your own GNS3 directory holds every project and image you created with the GUI, so copy out anything you want to keep before you delete it along with the GUI settings:

rm -rf ~/GNS3 ~/.config/GNS3

The same goes for the headless server: delete /var/lib/gns3 only once you have copied out any projects you want to keep, because the headless server stores every project there under its UUID. For the same lab on other systems, the GNS3 install guide for Ubuntu uses the official PPA instead of distro packages. Our notes on mini PCs for GNS3 and EVE-NG labs help when the topologies outgrow a laptop, and the GNS3 documentation covers appliance templates and IOS image import. On Fedora we’d run the GUI from the repositories on the workstation and the packaged service on a dedicated host, with the password set and the console range closed to everyone but you.