Migration from wicked to NetworkManager

English Network/Internet
#1

Hello,

In the openSUSE Release Engineering Meeting 26.01.2022 I see this information

Wicked is phasing out. New installations of Tumbleweed are all done by default using NetworkManager (not only desktop, but also server installs). nmtui is the tool to configure it. Upgraders are not (yet) planned to be migrated away from wicked.

In the more or less short term, I will have to do a migration from my wicked network to NetworkManager.

I have a home server working as a router with a pppoe connection to internet (device eno3), 4 vlans (device eno2) with different devices, and a bridge (for a VM, device eno1).
I run also DNS (bind), DHCP and ntpd servers and use firewalld

The pppoe connection is activated via a service after start of wicked.When pppoe interface starts, it changes the default route using the received IP address from my provider.

ip route show
**default dev ppp0 scope link **
**xx.xx.97.36 dev ppp0 proto kernel scope link src 91.176.217.91** 
192.168.1.0/24 dev vlan1 proto kernel scope link src 192.168.1.1 
192.168.1.120 via 192.168.1.120 dev br0 
192.168.2.0/24 dev vlan2 proto kernel scope link src 192.168.2.1 
192.168.3.0/24 dev vlan3 proto kernel scope link src 192.168.3.1 
192.168.4.0/24 dev vlan4 proto kernel scope link src 192.168.4.1

My connections are

# ip address
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq master br0 state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:12 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f0
3: eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f1
4: eno3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:14 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f2
5: eno4: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 9c:8e:99:5b:48:15 brd ff:ff:ff:ff:ff:ff
    altname enp2s0f3
6: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 5a:1a:d5:99:b3:b0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.120/32 scope global br0
       valid_lft forever preferred_lft forever
7: vlan1@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.1/24 brd 192.168.1.255 scope global vlan1
       valid_lft forever preferred_lft forever
8: vlan2@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.2.1/24 brd 192.168.2.255 scope global vlan2
       valid_lft forever preferred_lft forever
9: vlan4@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.4.1/24 brd 192.168.4.255 scope global vlan4
       valid_lft forever preferred_lft forever
10: vlan3@eno2: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether 9c:8e:99:5b:48:13 brd ff:ff:ff:ff:ff:ff
    inet 192.168.3.1/24 brd 192.168.3.255 scope global vlan3
       valid_lft forever preferred_lft forever
11: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1492 qdisc fq_codel state UNKNOWN group default qlen 3
    link/ppp 
    inet XX.YYY.217.91 peer XX.XX.97.36/32 scope global ppp0
       valid_lft forever preferred_lft forever

I looked for some data about NetworkManager and I think that I can create the connection via the next commands (from man nmcli-examples)
ppp0

[FONT=lucida console][size=2]nmcli connection add type pppoe username XXXXXXX@provider password yyyyyy  ifname ppp0 con-name ppp0 pppoe.parent en03
nmcli connection modify ppp0 802.mtu 1492[/FONT][/size]

vlans where x = 1,2,3,4

nmcli connection add type vlan con-name vlanx dev eno2 id x ip4 192.168.x.0/255 gw4 192.168.x.1

for the bridge br0

nmcli con add type bridge con-name br0 ifname br0
nmcli con add type ethernet con-name eno1 ifname eno1 master br0

Now my questions:
They suggest using the nmtui program but is it possible setting my configuration with it or is it better to use nmcli?
If I change in Yast the connection type from wicked to NetworkManager, disable the current pppoe.service and try the above commands is it possible going back to wicked type without recreating all the network settings?
How is it working with networkManager and pppoe for the default route?
I’m a bit doubtful about the definition for the bridge. Is it correct?
Should the VM connection work out of the box or do I need some additional configuration?
I want also that the interfaces are active immediately after the boot without login in KDE : Are there additional settings needed therefor?
I have read that NetworkManager use dnsmasq but I’m using named (bind) +dhcpd. Is this a problem? Are there additional settings required?

Many thanks in advance
Philippe

#2

Just as alternative. Switch from Wicked to systemd.networkd. To me that looks as a very straightforward solution for a “server” like system.

#3

Thanks for your answer.

I didn’t think to use systemd_networkd and looked in the related man.
At first sight it is not simple and i found less examples than for nmcli.
I’ll investigate further and see if I can use it.
If needed i’ll come back with my questions

Regards
Philippe

#4

I do of course not know yor exact situation, but in my situation configuring was easy and it runs ever since I did it (e.g. nothing to do on 15.2 >15.3 upgrade). These are the notes I made so I could easily post again by copy/post:

See this discussion for some background:
et0 not (auto) enabled at boot time no static ip-addresses are assigned starting at post #10.

For documentation of the systemd-networkd service:

man 8 systemd-networkd

man 5 systemd.network

=============================

As an example, what I have done (no DHCP, fixed IP-address, etc.).

Create /etc/systemd/network/20-wired.network:


[Match]
Name=eth0
  
[Network]
Address=10.0.0.254/24
Gateway=10.0.0.138

I assume you understand how to adapt the name of the NIC, the IP-addess/netmask and the gateway address to your situation.

Remove /etc/resolv.conf (It is often a symbolic link) and create a new one:


search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104

You may or many not want to use a search statement there and of course should use the IP-addresses of the nameserver(s) you prefer (maybe your router).

Use YaST > System > Services Manager to switch all services with “wicked” in the name to “Manually” and to switch the systemd-networks service to “On Boot”.

Reboot and test.

#5

DHCP is even easier:

**i3-4130:~ #** cat /etc/systemd/network/wlan.network  
[Match] 
Name=w* 

[Network] 
DHCP=yes 
Domains=fritz.box 
**i3-4130:~ #**

Resolver:

**i3-4130:~ #** ll /etc/resolv.conf 
lrwxrwxrwx 1 root root 32 Jun 19  2021 /etc/resolv.conf -> /run/systemd/resolve/resolv.conf 
**i3-4130:~ #**

https://en.opensuse.org/Network_Management_With_Systemd

#6

Karl, thanks for the addition (I assumed that your examples can be found using my link to the old thread in my post above).

About resolving. Can you inform me what that symlink to /run/systemd/resolve/resolv.conf is supposed to do?
In my system:

boven:/run/systemd # l resolve
ls: cannot access 'resolve': No such file or directory
boven:/run/systemd #

Thus such a link would not be a good idea IMHO, where my good old resolv.conf works already for more then 20 years.

#7

systemd-resolved fills in the addresses and the domain:

**i3-4130:~ #** systemctl list-unit-files systemd-resolved.service 
UNIT FILE                STATE   VENDOR PRESET
systemd-resolved.service **enabled ****disabled     **

1 unit files listed. 
**i3-4130:~ #** systemctl list-units systemd-resolved.service      
  UNIT                     LOAD   ACTIVE SUB     DESCRIPTION            
  systemd-resolved.service loaded active running Network Name Resolution 

LOAD   = Reflects whether the unit definition was properly loaded. 
ACTIVE = The high-level unit activation state, i.e. generalization of SUB. 
SUB    = The low-level unit activation state, values depend on unit type. 
**1 loaded units listed.** Pass --all to see loaded but inactive units, too. 
To show all installed unit files use 'systemctl list-unit-files'. 
**i3-4130:~ #** cat /etc/resolv.conf                               
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8). 
# Do not edit. 
# 
# This file might be symlinked as /etc/resolv.conf. If you're looking at 
# /etc/resolv.conf and seeing this text, you have followed the symlink. 
# 
# This is a dynamic resolv.conf file for connecting local clients directly to 
# all known uplink DNS servers. This file lists all configured search domains. 
# 
# Third party programs should typically not access this file directly, but only 
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a 
# different way, replace this symlink by a static file or a different symlink. 
# 
# See man:systemd-resolved.service(8) for details about the supported modes of 
# operation for /etc/resolv.conf. 

nameserver 192.168.178.1 
nameserver fd00::a96:d7ff:fee2:d6cf 
search fritz.box 
**i3-4130:~ #**

Thus such a link would not be a good idea IMHO, where my good old resolv.conf works already for more then 20 years.

Your good old resolv.conf contains static data, which need maintenance. systemd-resolved provides dynamic data and uses Domains from wlan.network. Virtually maintenance-free.

#8

My resolv.conf is the same for at least 17 years. And filling in the same date in that unit file does not really seem an improvement to me. And when I change ISP, I guess I have to change them in my maintenance free unit file the same way as in the real resolv.conf…

#9
  1. When I change the ISP and keep the Fritz!Box I need to change username and password only.
  2. When I replace the Fritz!Box by another model I need to change “Domains” only.
  3. When I move the machine to a different local network I need to change “Domains” only.
  4. When I move to a ipv4-only network I need to change to DHCP=ipv4 only.
  5. …

All changes are made in a single .network file. Link /etc/resolv.conf never changes.

When I change nothing I need not change anything. However assuming no changes will be made for the next 20 years is not a valid assumption. Thus symlinking /etc/resolv.conf to /run/systemd/resolve/resolv.conf is the preferred procedure. When users bring in their machine for maintenance I comment out Domains=TheirDomain and add my Domains=fritz.box if applicable and testing is desirable.

#10

Thanks , I have also found a post for vlan with systemd-networkd and I created the related files

cd /etc/systemd/network
# ls -l
total 48
-rw-r--r-- 1 root root  30 janv. 27 18:14 05-br0.netdev
-rw-r--r-- 1 root root  73 janv. 28 16:34 06-br0.network
-rw-r--r-- 1 root root  47 janv. 28 13:39 11-vlan1.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:40 12-vlan2.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:40 13-vlan3.netdev
-rw-r--r-- 1 root root  47 janv. 28 13:41 14-vlan4.netdev
-rw-r--r-- 1 root root 126 janv. 28 13:42 20-eno2vlan.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 21-vlan1.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 22-vlan2.network
-rw-r--r-- 1 root root 133 janv. 28 13:43 23-vlan3.network
-rw-r--r-- 1 root root 133 janv. 28 13:44 24-vlan4.network
-rw-r--r-- 1 root root  62 janv. 28 16:38 30-eno3.network

# cat 11-vlan1.netdev
[NetDev]
Name=vlan1@eno2
Kind=vlan
[VLAN]
Id=1

# cat 21-vlan1.network
[Match]
Name=vlan1@eno2
Type=vlan
[Network]
Description=vlan1 interface
[Address]
Address=192.168.1.1/24
[Route]
Gateway=192.168.1.1

# cat 20-eno2vlan.network
[Match]
Name=eno2
Type=ether
[Network]
LinkLocalAddressing=no
VLAN=vlan1@eno2
VLAN=vlan2@eno2
VLAN=vlan3@eno2
VLAN=vlan4@eno2

Remove /etc/resolv.conf (It is often a symbolic link) and create a new one:

search xs4all.nl
nameserver 194.109.6.66
nameserver 194.109.9.99
nameserver 194.109.104.104

You may or many not want to use a search statement there and of course should use the IP-addresses of the nameserver(s) you prefer (maybe your router).

My resolv.conf contains

search pce23.net samdom.pce23.net
nameserver 192.168.1.120
nameserver 195.238.2.21
nameserver 195.238.2.22

AFAIK it is generated from the data entered in YaST network (wicked). Is there something equivalent for systemd-networkd or do I need to do it manually?

Some questions :

  1. currently the pppoe connection is started via a service file (after network start) and it uses a configured interface (eno3) defined without IP address see
    https://paste.opensuse.org/18770202

https://paste.opensuse.org/18770202

My idea is that I must define a 30-eno3.network file with

# cat 30*
[Match]
Name=eno3
Type=ether
[Network]
LinkLocalAddressing=no

is this ok?

  1. the pppoe service file has this setting
[Unit]
Description=PPP link to %I
**After=network-pre.target network.service 
Before=network.target multi-user.target shutdown.target **

Are the after and before lines still valid or is there a change needed with systemd-networkd?

Use YaST > System > Services Manager to switch all services with “wicked” in the name to “Manually” and to switch the systemd-networks service to “On Boot”.

Reboot and test.

Ok seems easy to come back to wicked if I have problem with systemd-networkd :slight_smile:
Many thanks for your help
Philippe

#11

Hello,

I did a test this afternoon with systemd-networkd:(
In YaST I activated systemd-networkd service and disabled all wicked services.
During reboot I see that the pppoe service try to start before the network is ready

 # journalctl -b 2
an 29 23:18:19 hpprol2 pppd[921]: /usr/sbin/pppd: In file /etc/ppp/peers/proximus: unrecognized option 'eno3'
Jan 29 23:18:19 hpprol2 pppd[921]: In file /etc/ppp/peers/proximus: unrecognized option 'eno3'
Jan 29 23:18:19 hpprol2 systemd[1]: ppp@proximus.service: Control process exited, code=exited, status=2/INVALIDARGUMENT
Jan 29 23:18:19 hpprol2 systemd[1]: ppp@proximus.service: Failed with result 'exit-code'.
Jan 29 23:18:19 hpprol2 systemd[1]: Failed to start PPP link to proximus.

en03 is the interface used by ppp. These errors occur 2 times during the boot but on third restart it works because eno3 is starting

Jan 29 23:18:40 hpprol2 systemd[1]: ppp@proximus.service: Scheduled restart job, restart counter is at 2.
Jan 29 23:18:40 hpprol2 systemd[1]: Stopped PPP link to proximus.
Jan 29 23:18:40 hpprol2 systemd[1]: Starting PPP link to proximus...
Jan 29 23:18:40 hpprol2 pppd[1590]: Plugin rp-pppoe.so loaded.
Jan 29 23:18:40 hpprol2 pppd[1590]: Plugin rp-pppoe.so loaded.
Jan 29 23:18:40 hpprol2 pppd[1590]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
Jan 29 23:18:40 hpprol2 pppd[1590]: RP-PPPoE plugin version 3.8p compiled against pppd 2.4.8
Jan 29 23:18:41 hpprol2 pppd[1590]: pppd 2.4.8 started by root, uid 0
Jan 29 23:18:41 hpprol2 kernel: 8021q: 802.1Q VLAN Support v1.8
Jan 29 23:18:41 hpprol2 kernel: NET: Registered PF_PPPOX protocol family
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan1: netdev ready
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan3: netdev ready
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan2: netdev ready
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan4: netdev ready
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: eno2: Link UP
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan1: Link UP
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan2: Link UP
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan3: Link UP
Jan 29 23:18:41 hpprol2 systemd-networkd[910]: vlan4: Link UP
Jan 29 23:18:43 hpprol2 systemd-networkd[910]: eno3: Link UP 


Jan 29 23:18:56 hpprol2 pppd[1590]: PPP session is 1
Jan 29 23:18:56 hpprol2 pppd[1590]: Connected to 20:e0:9c:0a:cd:47 via interface eno3
Jan 29 23:18:56 hpprol2 pppd[1590]: Using interface ppp0
Jan 29 23:18:56 hpprol2 pppd[1590]: Connect: ppp0 <--> eno3
Jan 29 23:18:56 hpprol2 systemd-udevd[1638]: Using default interface naming scheme 'v249'.
Jan 29 23:19:00 hpprol2 pppd[1590]: Warning - secret file /etc/ppp/chap-secrets has world access
Jan 29 23:19:00 hpprol2 pppd[1590]: CHAP authentication succeeded: CHAP authentication success
Jan 29 23:19:00 hpprol2 pppd[1590]: CHAP authentication succeeded
Jan 29 23:19:00 hpprol2 pppd[1590]: peer from calling number 20:E0:9C:0A:CD:47 authorized
Jan 29 23:19:01 hpprol2 pppd[1590]: replacing old default route to vlan1 [192.168.1.1] with metric $d
Jan 29 23:19:01 hpprol2 pppd[1590]: local  IP address 91.176.217.91
Jan 29 23:19:01 hpprol2 pppd[1590]: remote IP address XX.XX.97.36
Jan 29 23:19:01 hpprol2 pppd[1590]: primary   DNS address 195.238.2.21
Jan 29 23:19:01 hpprol2 pppd[1590]: secondary DNS address 195.238.2.22
Jan 29 23:19:01 hpprol2 systemd-networkd[910]: ppp0: Link UP
Jan 29 23:19:01 hpprol2 systemd-networkd[910]: ppp0: Gained carrier
Jan 29 23:19:01 hpprol2 systemd[1]: Started PPP link to proximus.
Jan 29 23:19:02 hpprol2 pppd[1645]: Script /etc/ppp/ip-up finished (pid 1646), status = 0x0
Jan 29 23:19:51 hpprol2 kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
Jan 29 23:19:51 hpprol2 kernel: nf_conntrack: default automatic helper assignment has been turned off for security reasons and CT-based firewall rule not found. Use the iptables CT target to attach helpers instead.
Jan 29 23:20:19 hpprol2 systemd-networkd-wait-online[922]: Timeout occurred while waiting for network connectivity.
Jan 29 23:20:19 hpprol2 systemd[1]: systemd-networkd-wait-online.service: Main process exited, code=exited, status=1/FAILURE
Jan 29 23:20:19 hpprol2 systemd[1]: systemd-networkd-wait-online.service: Failed with result 'exit-code'.
Jan 29 23:20:19 hpprol2 systemd[1]: Failed to start Wait for Network to be Configured.
Jan 29 23:20:19 hpprol2 systemd[1]: Reached target Network is Online.

When boot is complete is see that the interfaces are up with the correct addresses but the route show multiples defaults

**hpprol2:~ #** ip route 
default dev ppp0 scope link  
default via 192.168.2.1 dev vlan2 proto static  
default via 192.168.3.1 dev vlan3 proto static  
default via 192.168.4.1 dev vlan4 proto static  
10.24.97.36 dev ppp0 proto kernel scope link src 91.176.217.91 
192.168.1.0/24 dev vlan1 proto kernel scope link src 192.168.1.1 
192.168.2.0/24 dev vlan2 proto kernel scope link src 192.168.2.1 
192.168.3.0/24 dev vlan3 proto kernel scope link src 192.168.3.1 
192.168.4.0/24 dev vlan4 proto kernel scope link src 192.168.4.1 
**hpprol2 #**

the lines default via 192.168.X.1 are not needed. I can delete it via ip route del.

Now the biggest problem: I use firewalld to manage different access for the pc on my lan and with systemd-networkd firewalld doesn’t see the vlan interfaces:O.
Only eno3 and ppp0 are present. This blocks access to internet for all pc on my lan.
Is there a problem with firewalld and systemd-networkd?

Back to wicked

Many thanks in advance
Philippe

#12

That is not a good experience. I am afraid that you set-up is much more complicated then mine.
Maybe Karl can help you.

#13

Thanks Henk,
The firewalld setting is not very complex. I give it below for info.
I’m searching on the internet about “systemd-networkd vlan firewalld” but I didn’t yet found something related.
I found for firewalld that it depends on the ifcfg* files and the zone defined therein. AFAIK systemd-networkd doesn’t use these files but they are still present from wicked.

I’m thinking that the pppoe and the firewalld have maybe the same problem: they are started before systemd-networkd has completed: pppoe doesn’t found eno3 and firewalld doesn’t found the interfaces for vlans (br0, eno1, eno2, vlanx).

firewalld settings

hpprol2:~ # firewall-cmd --get-active-zones
docker
  interfaces: docker0
external
  interfaces: eno3 ppp0
home
  interfaces: eno1 eno2 br0 vlan1 vlan2 vlan4 vlan3
hpprol2:~ # firewall-cmd --list-all
home (active)
  target: default
  icmp-block-inversion: no
  interfaces: br0 eno1 eno2 vlan1 vlan2 vlan3 vlan4
  sources: 
  services: apache2 apache2-ssl dhcp dhcpv6 dhcpv6-client dns dns-over-tls finger ftp http https imap imaps ipp ipp-client irc kdeconnect kerberos kpasswd ldap ldaps libvirt libvirt-tls libvirtd-relocation-server mdns minidlna mountd mysql nfs nfs3 ntp openvpn rpc-bind rsyncd samba samba-client samba-dc sane slp smtp smtps snmp ssh tftp tigervnc tigervnc-https transmission-client vnc-server
  ports: 67/udp 68/udp
  protocols: 
  forward: yes
  masquerade: no
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
        rule family="ipv4" source address="192.168.3.0/24" destination address="192.168.2.0/24" protocol value="tcp" drop
        rule family="ipv4" source address="192.168.2.0/24" destination address="192.168.3.0/24" protocol value="icmp" drop
        rule family="ipv4" source address="192.168.3.0/24" destination address="192.168.2.0/24" protocol value="icmp" drop
        rule family="ipv4" source address="192.168.2.0/24" destination address="192.168.3.0/24" protocol value="tcp" drop
hpprol2:~ # firewall-cmd --list-all --zone=external
external (active)
  target: default
  icmp-block-inversion: no
  interfaces: eno3 ppp0
  sources: 
  services: ssh
  ports: 
  protocols: 
  forward: no
  masquerade: yes
  forward-ports: 
  source-ports: 
  icmp-blocks: 
  rich rules: 
hpprol2:~ #

Regards
Philippe

#14

Firewalls must be started before network is up, otherwise you have some unprotected windows.

pppoe doesn’t found eno3

Interface exists independently of network management programs. Most likely pppoe is started before interface was renamed.

and firewalld doesn’t found the interfaces for vlans (br0, eno1, eno2, vlanx).
I found for firewalld that it depends on the ifcfg* files and the zone defined therein.

You misunderstand how firewalld works. You can bind interface to zone statically in firewalld configuration or dynamically at run time. wicked and NM support dynamic assignment; systemd-networkd does not, but you can do it statically. As long as interface names remain the same and are always associated with the same zone it will work just fine.

firewalld is not aware of ifcfg* files. wicked interprets them and tells firewalld to bind interface to zone indicated there.[/QUOTE]

#15

I do not know who “they” are but you can use any NetworkManager frontend that supports needed functionality. nmcli allows you to configure every property, but you must know exactly what to do. Other frontends (including nmtui) provide some sort of wizard that may be easier.

If I change in Yast the connection type from wicked to NetworkManager, disable the current pppoe.service and try the above commands is it possible going back to wicked type without recreating all the network settings?

Yes. Switch back to wicked, enable pppoe service.

How is it working with networkManager and pppoe for the default route?

I do not understand the question. For each NetowkrManager connection you can define whether to use this connection for default route or not.

I’m a bit doubtful about the definition for the bridge. Is it correct?

Just test it.

Should the VM connection work out of the box or do I need some additional configuration?

Again, I do not understand the question. Explain what you did now to configure connection.

I want also that the interfaces are active immediately after the boot without login in KDE : Are there additional settings needed therefor?

You set connection as “available to all users” and “automatically connect”. May be it is System connection in KDE.

I have read that NetworkManager use dnsmasq

It may use dnsmasq if you configure it to do so. It does no use it by default.

#16

Hello,

With wicked I created a pppoe service which when connecting replaces the default route by a new default route using the IP address received from my provider: this is controlled by setttings in file /etc/ppp/peers/xxx

# automatically set the PPP connection as your default route (for IPv4 only)
defaultroute
replacedefaultroute

. With pppoe active if have then this default route

# ip route show
default dev ppp0 scope link 
YY.YY.97.36 dev ppp0 proto kernel scope link src XX.X.XX.XX

With NetworkManger should I

  1. create a pppoe connection via nmcli via something like
nmcli connection add type pppoe  username myuser@PROXIMUS password mypasswd ifname ppp0 pppoe.parent eno3

and should the default route be set to pppoe?
or
2. no ppp connection via nmcli and still use my pppoe service?

Again, I do not understand the question. Explain what you did now to configure connection.

When I installed the VM software the bridge was automatically created enslaving the eno1 interface. I defined the VM (Xen) and on start the VM can connect to internet and to the host using a virtual network. As far as I remember I just defined in the VM that I use wicked and set a fixed IP address for the VM ( in the same network as the bridge). This create on the host a virtual interface which dissapear when the VM is shutdown. No other configuration needed

Many thanks in advance
Philippe

#17

Enable and start systemd-networkd-wait-online.service. firewalld.service has “Before=network-pre.target”.

#18

Hello Karl,

This service wait until the network is connected as far as I understand. Is network-pre.target set thereafter?
With systemd-network I had yesterday this for the critical chain

   systemd-analyze critical-chain 
The time when unit became active or started is printed after the "@" character. 
The time the unit took to start is printed after the "+" character. 

graphical.target @2min 11.360s 
└─multi-user.target @2min 11.359s 
 └─**dhcpd.service @2min 9.302s +2.056s**
   └─remote-fs.target @2min 9.291s 
     └─**iscsi.service @2min 9.215s +74ms**
       └─network-online.target @2min 9.202s 
         └─**ppp@proximus.service @29.686s +10.870s**
           └─**systemd-networkd.service @8.511s +354ms**
             └─network-pre.target @8.505s 
               └─**firewalld.service @5.464s +3.039s**
                 └─**polkit.service @3.925s +1.523s**
                   └─basic.target @3.852s 
                     └─sockets.target @3.850s 
                       └─pcscd.socket @3.849s 
                         └─sysinit.target @3.828s 
                           └─haveged.service @23.664s 
                             └─systemd-journald.socket 
                               └─system.slice 
                                 └─-.slice

As you can see there is much time needed for network-online.target
I’ll test your advice as soon as possible.

Regards
Philippe

#19

Hello arvidjaar,

If I understand correctly I need to use firewall-cmd to assign the interface to the zone something as

firewall-cmd --permanent --zone=home --add-interface=vlanx

Is this permanent after a reboot ? The other firewalld settings should still be present?
Another question: why did firewalld find the ppp0 and eno3 interfaces for zone external?

Many thanks in advance
Philippe

#20

Show the following:

systemctl cat ppp@proximus.service 
journalctl -b -u ppp@proximus.service

With the above network.target is reached when the links are up. You want the links configured, I presume. Thus enable systemd-networkd-wait-online.service and start [noparse]ppp@proximus.service[/noparse] after network-online.target is reached.