Netplan for Newbies

One of the newer features to Ubuntu (Integrated into 17.10, and a part of the 18.04 LTS build) is Netplan. Netplan, as a system, is what is replacing NetworkManager for handling network devices which means if you are doing any sort of real work with an Ubuntu server, you need to learn it.

Very simple configurations have been fleshed out in a few places, including Ubuntu’s own website. The problem is one of simplicity; it doesn’t necessarily talk about larger examples, nor potentially complex ones. It’s also a problem of newness- good resources on how to configure it for specific use-cases simply aren’t there.

So let’s try and rectify that!

In this example let’s say that you have a home server, and that home server has WiFi and has a single NIC. You want both the WiFi and NIC to be able to talk as they normally do, and you want to be able to create a network bridge using the NIC specifically for virtual machines to use. We want the NIC and WiFi elements to be static, and the bridge to provide DHCP addresses. Sounds a little complex, right? With Netplan it isn’t too bad, but we need to understand a few things.

Starting Out
Before you touch anything regarding the configuration, I’m going to recommend you at least take a look at the man page for Netplan, or some of the documentation written by its creators available here. Netplan configuration is in YAML, and while YAML is generally quick to sort out here is a great source to learn the ins and outs of the markup language.

To start in Netplan, we need to define the network. If you look in /etc/netplan, you’ll find a file ending in .yaml, that contains something like this:

What this means to us, the humble admin, is that NetworkManager is what is handling network devices by default. In order to get flexibility that Netplan provides, we need to change this renderer to use systemd-networkd. In configuration, that looks like this:

Once we’ve told networkd to take over from NetworkManager, we can move on to enumerating network devices, specifying how they should operate, and so on.

Let’s start with the NIC.

LAN Of The Free
To enumerate our network devices we have a few options based on the documentation. There are options to do all cards meeting certain criteria (Naming, MAC address, etc.), but I find the easiest way to do it for those servers that don’t have a bunch of interfaces is to just call out the device itself- keep it simple. From there, we assign properties such as the address we might want the device to have, the gateway, its name servers, and so on.

In my example of wanting a statically assigned NIC, the configuration might look like this:

Where eno1 is the name of the card when I show devices and configurations via the “ip addr” command.

2.4Ghz Magic
Setting up the wireless interface is relatively straightforward as well. The notable difference from the ethernet interface is the inclusion of the “access-points” parameter. Something we need to note here, and it’s critical, is that Netplan only supports WPA2- this means if you plan on trying to use Netplan on a laptop, you probably shouldn’t and instead stick with NetworkManager. Another note is that the passwords here are in plaintext- what this means is that if a sudoer or root account is compromised you may allow for an attacker to pivot deeper into your network or perform additional nefarious behaviors.

In the example, let’s pretend the access point I want to connect to is called “MyPoint” and the password is “STRONG_PASSWORD_PLS”.

Building a Bridge
Once the interfaces have been created, setting up a bridge is really easy. You simply give the bridge a name, list the interfaces, and it follows the same general pattern as our NIC and WiFi example. As mentioned in the initial example, the bridge is entirely DHCP- which makes setting it up even easier.

Putting It All Together
In the end, our configuration file looks something like this- of course, your mileage will vary simply because your system is not the example system:

Testing and Applying Your Creation
Once you have your YAML constructed (And potentially linted) and saved in /etc/netplan as a .yaml file, the next step is to test the configuration. The best way to do that is through the netplan command itself. By running

you can observe the full process of Netplan performing the interface configuration process, and it will tell you if there are any issues with your YAML (Or with how Netplan perceives your YAML). Once your configuration comes back clean, you can make the settings stick by running

and the settings should be applied- note that services will be restarted as necessary.

Questions, comments or concerns? Feel free to reach out to us below, or email us at IDMWORKS to learn more about how you can protect your organization and customers.

Leave a Reply

Your email address will not be published. Required fields are marked *