Use Netplan for Ubuntu network configuration
Netplan is Ubuntu’s declarative system for persistent network settings. It stores configuration in YAML files under /etc/netplan, then translates those files into settings for NetworkManager or systemd-networkd. That makes it practical for repeatable Ethernet, DNS, routing, and static-address tasks on laptops, servers, and small offices. This guide explains how to use Netplan for network configuration on Ubuntu, including the safer way to test a change before committing it.
Ubuntu Desktop usually manages connections through NetworkManager, while Ubuntu Server and many cloud images use systemd-networkd. The renderer selected in Netplan decides which backend receives the settings, so copying a file from one installation to another can produce unexpected results. Before editing anything, identify the active backend, inspect the existing files, and record the interface name and current gateway. For a remote machine, especially one reached over an NBN connection or an ISP business link, begin at the provider’s console or local keyboard rather than changing the only working path.
See which network backend is active
Netplan is a translator, not the service that directly moves packets. A YAML file describes desired outcomes such as using DHCP, assigning an address, or sending DNS queries to a particular resolver. Netplan merges the files in /etc/netplan, renders the result, and passes it to the selected renderer. This is why valid syntax can still leave an interface unmanaged when the renderer and the running network service do not agree.
On Ubuntu Desktop, NetworkManager is normally the renderer, and /etc/netplan/00-network-manager-all.yaml may already request that backend. Ubuntu Server and most cloud images generally use networkd. Run sudo netplan get to see the merged configuration, then use nmcli device status on a desktop or networkctl status on a server. If both tools are installed, the renderer in the YAML and the active system service should guide the choice.
Inspect the current Ubuntu network setup
Start with a read-only survey of interfaces, addresses, routes, and DNS. Use only the commands relevant to your installation, since a minimal server may not include NetworkManager and some desktop utilities may be absent.
ip -br link
ip -br addr
ip route
resolvectl status
nmcli device status
networkctl status
ls -l /etc/netplan
sudo cat /etc/netplan/*.yaml
Match the interface name to the hardware. It may be enp3s0, ens18, eno1, or wlp2s0; do not assume it is eth0. Record the current IPv4 address, prefix length, default gateway, and DNS servers. Also check whether /etc/netplan contains more than one YAML file, because Netplan reads them in lexical order and later definitions can override conflicting values.
Many Australian NBN services, including fibre, FTTC, and fixed wireless plans from Telstra, Optus, or smaller providers such as Aussie Broadband, place a router between the WAN and local devices. That router often supplies the address and gateway by DHCP. A computer may therefore already have a working 192.168.x.x address even though the public address belongs to the ISP router.
Create a safe Netplan YAML file
Keep a copy of the working configuration outside /etc/netplan, where Netplan will not read it. Then edit an existing file or create one with a clear name, such as 01-network.yaml. Avoid defining the same interface in several files unless the override is deliberate.
sudo cp -a /etc/netplan "/root/netplan-backup-$(date +%F-%H%M)"
sudo touch /etc/netplan/01-network.yaml
sudoedit /etc/netplan/01-network.yaml
YAML is sensitive to layout. Use spaces rather than tabs, put a space after each key’s colon, and indent list items consistently beneath their key. A misplaced indentation mark can silently attach an address to the wrong interface. Keep credentials out of the file, and restrict access because the directory contains sensitive network details:
sudo chmod 600 /etc/netplan/01-network.yaml
sudo netplan generate
netplan generate checks the files and creates the backend configuration without putting it into service. If it reports an error, correct that first. Before changing an unfamiliar adapter, the linked network troubleshooting reference can also help distinguish a driver or hardware problem from a YAML mistake.
Configure a dynamic connection with DHCP
DHCP is the simplest and usually safest starting point because the router manages the local address, lease, default route, and often DNS. This example suits an Ubuntu desktop using NetworkManager:
network:
version: 2
renderer: NetworkManager
ethernets:
enp3s0:
dhcp4: true
Change enp3s0 to the name found during inspection. On a server using networkd, set renderer: networkd and ensure systemd-networkd is installed and enabled. If the NetworkManager renderer is already declared in another file, keep the backend consistent rather than adding a conflicting renderer for the same interface.
After editing, generate the configuration and test it. A DHCP connection should obtain a non-link-local IPv4 address and a default route. The lease may take a few seconds to refresh after switching from a manual address. If the interface fails to reconnect, use the rollback procedure described below rather than repeatedly applying more changes.
Assign a static IPv4 address
A fixed address is useful for a dedicated server, a network appliance, or a business service that must be reachable at a known local address. Disable DHCP for that interface, then define the address, route, and resolver explicitly. The example below uses networkd; use renderer: NetworkManager on an Ubuntu desktop installation.
network:
version: 2
renderer: networkd
ethernets:
enp3s0:
dhcp4: false
addresses:
- 192.168.20.50/24
routes:
- to: default
via: 192.168.20.1
nameservers:
addresses:
- 1.1.1.1
- 9.9.9.9
The values must match the actual network. 192.168.20.50/24 and gateway 192.168.20.1 are examples, not universal router settings. Choose an address outside the router’s DHCP pool, and do not use the router address itself. If the router uses 192.168.1.0/24, for example, a 192.168.20.0/24 address would put the host on the wrong subnet unless an additional route were configured.
Australian offices in Sydney, Melbourne, and Brisbane often obtain a public static WAN address from a business provider rather than using a home-style private subnet. Carrier-delivered static service can arrive with a provider-specific prefix and gateway, such as a small routed block rather than a /24. Enter the exact values in the provider’s handover document; copying the example into a public WAN configuration can create routing or conflict problems. Use the internal DNS resolver when the organisation operates one, since public resolvers cannot resolve internal hostnames.
Add DNS, IPv6, and wireless connections
DNS settings belong under the interface’s nameservers block. IPv4 and IPv6 resolver addresses may be mixed, while search supplies a local domain suffix. For example, an Australian business using an example.com.au domain might add search: [example.com.au] to complete short internal names. A company with an internal resolver should list it first and use a public fallback only when appropriate. Add this block beneath network::
ethernets:
enp3s0:
dhcp4: true
nameservers:
addresses:
- 1.1.1.1
- 9.9.9.9
search:
- example.com.au
Do not disable IPv6 merely to avoid seeing more than one address. Many NBN customers receive IPv6 through DHCP or router advertisements, while every active interface also has a link-local address. With networkd, dhcp6: true and accept-ra: true allow normal IPv6 configuration; omit dhcp6 if the provider uses stateless router advertisements only. Check the result with ip -6 address and ip -6 route.
On Ubuntu Desktop, use NetworkManager for Wi-Fi rather than storing a passphrase directly in a Netplan file. Connect to a café or office network with nmcli device wifi list, followed by nmcli --ask device wifi connect "Network Name". The prompt keeps the password out of shell history, and NetworkManager stores the connection profile for later use. This is particularly handy on hybrid laptops that move between an Ethernet dock and Australian café, airport, or shared-office Wi-Fi.
Validate, apply, and preserve the configuration
Run the generator before every application, not just when the file changes dramatically. It catches common YAML mistakes and refreshes the generated backend files:
sudo netplan generate
sudo netplan get
If generation succeeds, use sudo netplan try from a local console on a remote system. Netplan applies the new settings temporarily and rolls them back if the change is not confirmed. On a local workstation, sudo netplan apply is the normal persistent operation. After confirming a trial, run sudo netplan apply once more to leave the generated runtime state fully settled.
Verify the interface, route, and DNS rather than judging success by the absence of an error message:
ip -br address
ip route
resolvectl status enp3s0
ping -c 3 1.1.1.1
resolvectl query ubuntu.com.au
Some networks block ICMP, so a failed ping does not by itself prove the host is offline. Service logs provide better detail: use journalctl -u NetworkManager -n 50 on a desktop or journalctl -u systemd-networkd -n 50 on a networkd system. Keep the backup, record the final interface settings, and retest after a reboot to catch differences between the live session and the saved configuration. With console access available, the next action is sudo netplan try; confirm the address, default route, and DNS lookup before leaving the console.