On a two-NIC Ubuntu server, route one internal destination network through its internal gateway while keeping the existing default route. This example sends 172.16.50.0/24 through 192.168.20.1 on ens19. Add that route to the relevant Netplan configuration without replacing unrelated interface settings.
It covers Netplan configuration for Ubuntu 24.04·26.04, and also describes an alternative to managing NetworkManager profiles directly. Rather than deciding on a management method just by looking at the version, check the renderer and settings source of the NIC first.
On this page
Destination·Gateway·NIC classification
| item | example value |
|---|---|
| Management network NIC | ens18 · 192.168.10.50/24 |
| default gateway | 192.168.10.1 |
| Internal network NIC | ens19 · 192.168.20.10/24 |
| internal network router | 192.168.20.1 |
| Destination band/server | 172.16.50.0/24 · 172.16.50.20 |
Assume that the server’s ens19 address is already set to 192.168.20.10/24. Since the destination 172.16.50.0/24 is not in a directly connected band, it is passed to router 192.168.20.1 on the same link. The router and the other party must also have forwarding and return paths prepared.
Static IP and static routing are different settings. If you need to configure IP·DNS first, check Ubuntu 24.04 Static IP Settings or Ubuntu 26.04 Two NIC Configuration first.
1. Check the actual network management method
cat /etc/os-release
ip -br address
ip -4 route show
ls -l /etc/netplan/
sudo netplan get
systemctl is-active systemd-networkd NetworkManagerNetplan reads YAML settings and generates settings for use by systemd-networkd or NetworkManager. Configuration may vary depending on Server·Desktop·Cloud image. Even if both services are running, that doesn’t mean they are both managing the same NIC.
Read the settings of the corresponding NIC and renderer from sudo netplan get, and check ownership with networkctl status ens19 for the networkd environment and nmcli device status for the NetworkManager environment. If the Netplan YAML is the source, routes are managed in that YAML. For an overview, refer to Ubuntu Server network document.
Also check the address of the SSH connection PC and the current return path. The address below is an example, so replace it with the address of the actual connected PC. Have a backup of your console access and settings before making any changes.
ip -4 route get 192.168.10.100
ip -4 route get 192.168.20.1
ip -4 route get 172.16.50.20
BACKUP_DIR="/root/netplan-route-backup-$(date +%Y%m%d-%H%M%S)"
sudo install -d -m 700 "$BACKUP_DIR"
sudo cp -a /etc/netplan "$BACKUP_DIR/"Files that the image deployment tool creates, such as 50-cloud-init.yaml, also check the settings source. In environments where cloud-init recreates the network, manual changes may be overwritten later. Decide whether to replace the original or switch to manual management and then modify it. There is no need to turn off the entire cloud-init for the static path in this article.
2. Check communication with temporary route first
sudo ip route add 172.16.50.0/24 via 192.168.20.1 dev ens19 metric 100
ip -4 route get 172.16.50.20
ping -c 3 -W 1 172.16.50.20This command only reflects on the current kernel. In a correct configuration, the path will be selected in the form: It also verifies that the address actually exists and that the next hop is reachable.
172.16.50.20 via 192.168.20.1 dev ens19 src 192.168.20.10When you’re done with your temporary exam, clear it and save it as Netplan. If File exists is displayed because the same path already exists, read the existing path and determine whether it is a duplicate. Do not delete the default path or anything else to get rid of this error.
sudo ip route del 172.16.50.0/24 via 192.168.20.1 dev ens19 metric 1003. Add routes to existing Netplan NIC
Keep the addresses, DNS, DHCP and renderer settings, and append only the destination entry to the interface’s existing routes: list. The snippet shows where to add the route; it is not a replacement for the entire existing file.
# 기존 NIC의 routes 목록에 합칩니다. 기존 주소와 renderer는 유지합니다.
network:
version: 2
ethernets:
ens19:
routes:
- to: 172.16.50.0/24
via: 192.168.20.1
metric: 100If you already have routes:, add entry - to: to the same list. Do not create routes: twice inside the same YAML mapping. If you defined a device with an ID like internal: instead of ens19 and match:, place it under that existing ID.
to is the destination, via is the next hop, and metric is a value used when comparing paths of the same destination/prefix. This is different from adding to: default to the internal network. The setting items are defined in Netplan routing format.
Complete file for practice configuring two NICs for the first time.
Below is the complete configuration for networkd, including all of the preceding example addresses. Only new lab VMs will use this address and configuration; existing servers will only reflect the path entries described previously. There is only one default route on the management network and a specific band route on the internal network.
network:
version: 2
renderer: networkd
ethernets:
ens18:
dhcp4: false
addresses: [192.168.10.50/24]
routes:
- to: default
via: 192.168.10.1
metric: 100
nameservers:
addresses: [192.168.10.1]
ens19:
dhcp4: false
addresses: [192.168.20.10/24]
routes:
- to: 172.16.50.0/24
via: 192.168.20.1
metric: 100When using the entire file for practice, save it with a name such as /etc/netplan/60-routing-lab.yaml and set the permissions to sudo chmod 600 /etc/netplan/60-routing-lab.yaml. If you have already defined the same NIC in another YAML, check the merge results first. Sequences such as path lists can be merged, so you should not assume that a single new file will replace all existing items.
4. Check syntax and apply with netplan try
sudo netplan get
sudo netplan generate
sudo netplan try --timeout 120generate checks settings and creates files for the backend, but does not reconfigure the running network. If there are any errors, correct the YAML indentation and keys before applying. In the document Netplan generate, we distinguish between the two operations.
try ensures that changes are confirmed within a time limit. While waiting for confirmation, reconnect to SSH from another terminal and check the path/communication below and approve it from the original terminal. If you can’t connect, check the status in the console.
ip -4 route show 172.16.50.0/24
ip -4 route get 172.16.50.20
ip -4 route show default
ping -c 3 -W 1 172.16.50.20After try times out or is cancelled, verify that the effective routes actually reverted. Check the YAML on disk before rebooting as well. The known issues in the official try documentation explain why automatic recovery still needs verification.
If you are working in the console and are ready to apply changes right away, you can use sudo netplan apply. The approved YAML will also be used as the settings source on the next boot. After maintenance reboot, recheck ip route get and service connection.
5. Specify only one server or delete the route
To specify only one specific server, write /32 in the destination. Place the following entry in the routes: list for the required NIC: The code below showing one entry is not a standalone entire Netplan file.
- to: 172.16.50.20/32
via: 192.168.20.1
metric: 100In the same table, /32 is more specific than /24, so it is selected first. Writing a wider band with a lower metric does not overturn this priority. If origin-specific table selection is required, this is treated as a separate policy routing problem.
When deleting, we only remove the destination items we added in the original YAML. If there are any other paths, it leaves a list, and clears the empty routes: key only when there are no more entries. Apply again as generate and try.
sudo netplan generate
sudo netplan try --timeout 120
ip -4 route show 172.16.50.0/24
ip -4 route get 172.16.50.20If the route you added is removed, the destination may be looked up using the existing default route or another matching route. Items deleted only from the kernel with sudo ip route del are recreated in YAML at the next apply or reboot, so permanent deletion is done from the original file.
6. When managing NetworkManager profiles directly
If you are managing the source of the NIC in an existing environment with a NetworkManager profile, use the following method. Modifying the same NIC in both Netplan YAML and nmcli alternately makes it difficult to trace the original. When using a profile created by Netplan, the preceding YAML path takes precedence.
nmcli -f NAME,UUID,TYPE,DEVICE connection show --active
nmcli -g GENERAL.CONNECTION device show ens19
PROFILE='internal-lan'
sudo nmcli connection modify "$PROFILE" \
+ipv4.routes "172.16.50.0/24 192.168.20.1 100"
sudo nmcli device reapply ens19
ip -4 route get 172.16.50.20Replace internal-lan with the actual profile name you saw earlier. To delete, specify the same item as -ipv4.routes and reapply. If you need to reactivate your profile, do so from the console as your connection may be lost. For detailed addition and deletion examples, refer to the nmcli static routing article and the NetworkManager article .
7. When applied but not connected and SSH recovery
ip -4 route get 172.16.50.20 from 192.168.20.10
ping -c 3 -W 1 192.168.20.1
ip neigh show dev ens19
ip -4 rule show
ip -4 route show table all| symptoms | Next check |
|---|---|
| Gateway is invalid | ens19 Check whether the address/prefix and the gateway are the same link |
| Exit to default gateway | Destination typo, more specific path, check ip rule and other tables |
| Path is correct but no response | Check whether the next hop has been reached, the router’s forwarding/ACL, and the other party’s return path |
| Path disappears after reboot | ip route Check whether you have only temporary settings and whether permanent settings are loaded. |
The destination server and intermediate routers also need a route to return a response with 192.168.20.0/24. If the connection is made by IP but only the name fails, the DNS is checked separately, and if only ping is blocked, the allowed service port is checked. Two-way communication is not guaranteed based on only the path of the server from which the packet originates.
If the Ubuntu server is responsible for relaying packets from other devices between two NICs, you must also configure IP forwarding and forwarding firewall policies. The scope is different from this example, which adds a static route to a regular host. Roles are classified based on the IP forwarding description of the kernel. .
If SSH is disconnected, first check ip route and the direction of the actual connected PC on the console. Remove the incorrectly added path in the original YAML or restore the corresponding file from the backup, then restore it to sudo netplan generate and sudo netplan apply in the console. If a newly created practice file is the cause, remove only that file and keep the existing file. Compare modified files to ensure that changes made after other operations are not overwritten by backups.
Example download and verification scope
Ubuntu Static Routing Example ZIP contains a route fragment to be added to an existing NIC, a full configuration for both NICs, a /32 entry, and a confirmation command. On the actual server, refer to the path fragment and add only the necessary items to the existing configuration. First, check the next hop and destination, and after applying, check the management network and in-house service connection.
On October 23, 2026, after creating the settings in Netplan 1.1.2 and systemd 255 in the Ubuntu 24.04.5 container, we confirmed the actual communication of the route applied with networkd and the maintenance of the route after restarting the renderer. Also checked creation of settings in Netplan 1.2 on Ubuntu 26.04 container, offline creation of profile with paths in NetworkManager 1.54.3. The test was conducted on an isolated virtual link, and actual VM reboot, timeout recovery of netplan try, and SSH disconnection recovery were not included in the execution verification.
