I'm trying to set up networking with netplan and networkd as renderer on an 18.04 machine. It runs the desktop distribution because it's connected to my TV and used for multimedia, but I'll call it a server because it's easier to explain and will run dns & dhcp servers once I get the network up and running properly.

I noticed that when I configure the network via netplan, I can't ping the server from my Windows 10 clients (not tested on other OS') unless I ping the said client from the server first. On the clients, I get:

Reply from [CLIENT'S OWN IP]: Destination host unreachable.

But after pinging from the server first, the client has an ARP entry and all is well.

I've searched solutions for far too much time and confirmed that:

  • Subnets are correct - everything is DHCP from my router at the moment to rule this out
  • There is no MAC or IP address conflict
  • Power management is off on the interface
  • It doesn't seem like a driver issue given the only change is network-manager vs networkd
  • Firewalls are OK
  • Router is OK

At the moment the machine is connected via WiFi and to change the configuration away from network-manager I just renamed /etc/netplan/01-network-manager-all.yaml so it's not used, and created /etc/netplan/config.yaml as follows:

    version: 2
    renderer: networkd
            dhcp4: yes
            dhcp6: no
                    password: "MyPassword"

/etc/network/interfaces is just iface lo inet loopback

I read that disabling of network-manager wasn't required as it will just report that interfaces configured manually are unmanaged, so the above change is all I have made.

Using Wireshark I confirmed that when configured with netplan, the server doesn't receive ARP packets when I ping from a client with no ARP entry for the server IP. It does receive them when network-manager is taking care of the interface; first one to tell the router, then one to tell the client.

Thanks in advance for any help!

EDIT 1: additional information:

/etc/NetworkManager/system-connections/[NETWORKNAME] is:






The netplan-generated networkd configuration at /run/systemd/network/10-netplan-wlp3s0.network is:




EDIT 2: a closer look at Wireshark shows that when using systemd-networkd configuration, there is no IGMP activity, no MDNS activity other than where the server is the source, and the only ARP activity is between gateway and server, until the server attempts to ping a client. Once the server attempts to ping the client, the first ARP is 'who has Client IP tell server IP', then immediately following, 'who has server IP, tell client IP', and finally the ping goes out to the client. From here on, the client can ping the server.

The whole time, the server can access any network services, internal and external.


After realising I was affected by this bug and correcting for it, I found that networkctl showed the wireless interface as 'configuring' status.

I then found that NetworkManager was running, and on stopping it via sudo systemctl stop NetworkManager, followed by sudo systemctl restart systemd-networkd, and finally deleting the ARP entry on my Windows client before pinging again, everything worked. I did sudo systemctl disable NetworkManager and restarted to make sure the solution persisted and it did not...

A kind soul in the Ubuntu IRC channel guided me to do:

sudo systemctl mask network-manager.service
sudo systemctl mask NetworkManager-dispatcher.service
sudo systemctl mask NetworkManager-wait-online.service

This resolved the issue and networkctl now shows the status of 'configured'. It appears network-manager and systemd-networkd were fighting over configuration of the wireless interface. I suspect that my understanding that network-manager would leave it alone would be correct if there was no configuration in /etc/NetworkManager/system-connections/ but haven't tested this theory - I'm just relieved it's resolved.

  • This helped me a lot. Thanks Tim. – user184371 Jul 17 '20 at 18:56

I had the same issue, on a recent 18.04 LTS server install, that I was also setting up VNC access on. As a result of the GUI install:

root:~# apt install lxde ssvnc

I ended up with network-manager on the machine, along with systemd-networkd (and systemd-resolved etc.). I could only access machines on the local network from the server, nothing outside of the local LAN, and nothing could connect in on ssh. Ping also failed.

As confirmation of your approach, I also ended up disabling network-manager, as it is very much the biggest hammer on the system, and I found that it tried to totally take over network config and DNS (resolv.conf) irrespective of what was already installed. I could only get things to work once I had logged into the GUI, and used network-manager to configure things. This makes (perfect) sense for a desktop user - just make it work.

Instead of hiding the service, I did:

root:~# apt list network-manager
Listing... Done
network-manager/bionic-updates,bionic-security,now 1.10.6-2ubuntu1.1 amd64 [installed,automatic]
N: There is 1 additional version. Please use the '-a' switch to see it
root:~# apt remove network-manager

Otherwise the various network services fight over the config of the machine. After nuking network-manager, I then setup the machine via netplan, and left systemd-resolved as the only nameserver service. The only further change I made was to change the "/etc/resolv.conf" symlink from pointing to the systemd-resolved stub service on (/run/systemd/resolve/stub-resolv.conf) to the alternative file, to expose the actual configured nameservers directly (/etc/resolv.conf -> ../run/systemd/resolve/resolv.conf).

After that, all was working as expected for me as well.

[EDIT] My learning was that network-manager is a great service for active desktop usage, but not for a command-line server or unattended desktop. By default the 18.04 LTS server ISO does not install network-manager... but it arrives if you install GUI for VNC etc. The VNC GUI works just fine without network-manager.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.