GNS3 Docker container has no internet: how to fix it

Your Docker node in GNS3 can't ping 8.8.8.8, or it pings addresses but apt update fails with Temporary failure resolving. Unlike a plain docker run, GNS3 starts containers with Docker's own networking turned off. The container only has the links you draw, and they have no address until you give them one.

Why it happens

Three settings must line up, and GNS3 leaves all of them to you.

No network by default. The GNS3 server creates each container with Docker networking disabled (NetworkDisabled in docker_vm.py). It mounts its own /etc/network and writes a sample /etc/network/interfaces in which every line is a comment. At start, GNS3's init script runs ifup -a -f. With nothing uncommented, eth0 comes up with no address and no route.

No path out. Internet access goes through a NAT node or a Cloud node. The GNS3 NAT node documentation says it needs the GNS3 VM or a Linux computer with libvirt, which provides the virbr0 bridge. It runs a DHCP server in 192.168.122.0/24, or 192.168.42.0/24 on recent GNS3 VMs. If the NAT node runs somewhere it can't work, GNS3 says so:

• On Linux: NAT interface virbr0 is missing, please install libvirt
• On Windows or macOS: NAT interface vmnet8 is missing. You need to install VMware or use the NAT node on GNS3 VM

No DNS. The sample static block in the file points DNS at 192.168.0.1, which isn't the NAT node. With a static address, unless you change it, the container has a route but can't resolve names.

On a Linux host, one more thing can get in the way. When Docker turns on IP forwarding itself, it also sets the firewall's forwarding policy to drop, which stops the host acting as a router. The Docker packet filtering documentation describes it, and gns3-server#2832 covers the pitfalls it causes for GNS3 on the same host.

The fix

1. Add a NAT node and link it

Drag a NAT node from the End devices category into the project. On Windows or macOS, run it on the GNS3 VM. On a Linux host, the local server works if libvirt is installed. Link the container's eth0 to the NAT node's nat0. For several containers, put a switch between them and the NAT node, since nat0 is its only port.

2. Turn on DHCP in the container

Stop the container. Right-click it and choose Edit config. GNS3 opens the container's /etc/network/interfaces. Find the DHCP block for eth0 and remove the # in front of its lines:

# DHCP config for eth0
auto eth0
iface eth0 inet dhcp
	hostname alpine-1

Click Save and start the container. GNS3 ships its own DHCP client script, which sets the address, the default route and /etc/resolv.conf from the lease.

3. Or use a static address

If you prefer a fixed address, uncomment the static block instead and change it to match the NAT subnet. This is the example from the GNS3 NAT node guide, with a public DNS server:

auto eth0
iface eth0 inet static
	address 192.168.122.25
	netmask 255.255.255.0
	gateway 192.168.122.1
	up echo nameserver 8.8.8.8 > /etc/resolv.conf

On a recent GNS3 VM, use the 192.168.42.0/24 addresses instead. If unsure, try DHCP once and note the subnet it gives you.

4. On a Linux host, check libvirt and the forwarding policy

The NAT node needs libvirt's network to be running:

ip addr show virbr0
sudo virsh net-list --all
sudo virsh net-start default
sudo virsh net-autostart default

If Docker runs on the same host, check the policy of the forwarding chain:

sudo iptables -S FORWARD | head -n 1

If it prints -P FORWARD DROP, the Docker documentation's option is to add "ip-forward-no-drop": true to /etc/docker/daemon.json, then restart Docker. Check first that your version knows it, with dockerd --help | grep ip-forward-no-drop, because the daemon won't start with an option it doesn't recognise.

sudo systemctl restart docker

This step doesn't apply to the GNS3 VM, which enables forwarding before Docker starts.

How to check it worked

Open the container's console and test each layer in order:

ip addr show eth0
ip route
ping -c 3 192.168.122.1
ping -c 3 8.8.8.8
cat /etc/resolv.conf
nslookup gns3.com

You should see an address in the NAT subnet, a default route via the .1 gateway, replies from the gateway and from 8.8.8.8, a nameserver line, and an answer to the lookup. The first step that fails tells you where to look: no address means DHCP or the link, no reply from the gateway means the NAT node, no reply from 8.8.8.8 means forwarding or the host's own connection, and failed lookups mean DNS. Minimal images may lack ping or nslookup, so use an image that includes them for this test.

If it still fails

• The NAT node won't start on Linux. The NAT node attaches to a host interface through uBridge, so uBridge needs network capabilities. See GNS3 "uBridge requires root access".
• Docker can't pull the image. If GNS3 says Could not pull the '...' image from Docker repository, please check your Internet connection, the GNS3 VM or Linux host itself is offline. Fix the host's connection first. For the GNS3 VM, check its network adapters in your hypervisor.
• It worked, then stopped after sleep. Users report the NAT node losing internet after the host or the GNS3 VM was suspended (gns3-server#1827). Restarting the GNS3 VM brings it back.
• Your DNS fix doesn't survive a restart. Put the nameserver in /etc/network/interfaces with an up echo nameserver ... line, as above, rather than editing /etc/resolv.conf by hand. GNS3 keeps /etc/network in the node's folder in the project and applies it with ifup -a -f at every start.
• The VM itself is unreachable. See GNS3 "Cannot connect to compute".

The GNS3 troubleshooting guide collects the other common errors.

Or skip the GNS3 VM

If your lab is made of containers, you can also draw it in Isothrum's editor, in the browser and without an account, and export it as Docker Compose files. It runs with docker compose up on any machine with Docker, with no GNS3 VM and no nested virtualization. You can still give each link latency, jitter, loss or a bandwidth limit. It doesn't change how GNS3 networks containers, but for a lab of containers it removes the VM layer.