GNS3 console not opening: how to fix telnet consoles

You double-click a node or choose Console from its menu, and no window appears. Or a terminal flashes open and closes, or it opens and shows Connection refused or a blank screen. GNS3 doesn't contain a terminal of its own: it starts an outside program with a telnet command, so the cause is almost always the node's state, that program, or the network path to the console port.

Why it happens

When you ask for a console, GNS3 reads the command from Edit > Preferences > General > Console applications, fills in {host}, {port} and {name}, and runs it. The GNS3 console terminal documentation describes this setting. Four things can go wrong.

1. The node isn't running. In the GUI code (telnet_console.py), GNS3 silently does nothing for a stopped node. No error, no window.

2. The program doesn't exist. The default depends on how you installed GNS3:

   • Windows: Solar-PuTTY, but only if Solar-PuTTY.exe is present. The GNS3 docs note that it ships only with the installer downloaded from gns3.com. Otherwise the default is PuTTY.
   • macOS: Terminal, driven by a script that runs telnet. Apple removed telnet from macOS 10.13, so GNS3 started shipping its own copy inside the app (gns3-gui#2274).
   • Linux: GNOME Terminal, MATE Terminal or Ptyxis on Debian, Ubuntu and Mint, and xterm elsewhere. Every Linux preset runs telnet {host} {port}, so the telnet client must be installed.

   When the program can't start, GNS3 writes Could not start Telnet console with command followed by the command and the error in its Console panel. When the terminal starts but telnet is missing, the window opens and closes at once.

3. The console port isn't reachable. Each node listens on a TCP port on the machine that runs it, from 5000 to 10000 by default. For the local server that is your own computer. For the GNS3 VM, it is the VM's IP. If your computer can't reach the VM, you get Connection refused or a timeout.

4. The device prints nothing. For a QEMU VM, the telnet console is the VM's first serial port. A guest that only writes to its screen leaves the telnet window blank.

The fix

1. Start the node

Start the node and wait for it to show as started in the Topology Summary panel. Then open the console again. Routers can take a minute or more to boot, so press Enter a few times.

2. Read the GNS3 error

Open View > Docks > Console if the panel is hidden. Try the console again and look for Could not start Telnet console with command. The error after the command, such as "No such file or directory" or "The system cannot find the file specified", tells you the program is missing or the path is wrong.

3. Choose a console command that works on your system

Go to Edit > Preferences > General > Console applications and click Edit next to the Telnet command. Pick a preset for a terminal you actually have. If the program isn't on your PATH, put its full path in the command, as the GNS3 docs advise. To test another program once, right-click the node and choose Custom console.

On Windows, if Solar-PuTTY is missing, choose Putty (normal standalone version) or Windows Terminal. Note that the Windows Terminal and Telnet presets call Windows' own telnet.exe, which is an optional feature. Tick Telnet Client in Turn Windows features on or off, or run this from an administrator prompt:

dism /online /Enable-Feature /FeatureName:TelnetClient

4. Install a telnet client on macOS or Linux

Check that it exists:

command -v telnet

If nothing prints, install it:

# Ubuntu, Debian, Mint
sudo apt install telnet
# Fedora
sudo dnf install telnet
# Arch (the GNS3 install guide lists inetutils as a prerequisite)
sudo pacman -S inetutils
# macOS with Homebrew, for presets other than GNS3's Terminal ones
brew install telnet

5. Test the port by hand

Right-click the node and choose Show node information. It shows a line like Console is on port 5000 and type is telnet, and the server it runs on. Connect to it yourself:

telnet 127.0.0.1 5000

For a node on the GNS3 VM, replace 127.0.0.1 with the VM's IP, shown in the Servers Summary panel. On Windows without a telnet client, test the port with PowerShell:

Test-NetConnection -ComputerName 192.168.56.101 -Port 5000

If the manual connection works, GNS3's command is the problem: go back to step 3. If it fails, the problem is the network path to the server.

How to check it worked

Double-click the node. A terminal window should open with the node's name as its title, and pressing Enter should give you a prompt, such as Router> on a Cisco router or a login prompt on Linux. Open a second node's console to make sure the fix isn't limited to one device type.

If it still fails

• The node's console type isn't telnet. In the node's Configure dialog, a QEMU node can use vnc, spice or none instead of telnet. With none, there is nothing to open. With vnc, GNS3 starts a VNC viewer instead, configured on the VNC tab of the same preferences page.
• A Docker node gives no prompt. The console shows what the container's start command prints. If that command is a service rather than a shell, you see logs but no prompt. As the GNS3 Docker docs put it, the start command is like the init process, and often you just want a shell, such as /bin/sh.
• The GNS3 VM isn't reachable. If you can't reach any port on the VM, the problem is the link between your computer and the VM. See GNS3 "Cannot connect to compute".
• A blank QEMU console. Configure the guest to use its serial console, or switch the node's console type to vnc to see its screen.

The GNS3 troubleshooting guide lists the other common errors, including Docker nodes without internet.

A lighter way to build the lab

If your network lab is mostly Linux containers, Isothrum's editor lets you draw it in the browser, with no account, and export it as a Docker Compose file. You then open a shell in any machine with docker compose exec, with no console ports to manage. Our desktop app, coming soon, will run labs locally with built-in consoles.