Default rules conflict with DHCP

[eliasp]

It looks like the default rules conflict with systemd-networkd's builtin DHCP server.

How to reproduce:

• Run a system with:

  • firewalld (e.g. Fedora 22)
  • systemd 219 (or newer)

• Launch a new systemd-nspawn container with veth networking:

  systemd-nspawn --network-veth -bxD /var/lib/machines/centos7.1-base

What should happen:

• systemd-nspawn creates the network interface ve-centos71-b

• systemd-networkd running on the host picks up the network interface and configures it according to the configuration below (including running a minimal DHCP server to hand out IP configurations to containers):

  [Match]
  Name=ve-*
  Driver=veth
  
  [Network]
  # Default to using a /28 prefix, giving up to 13 addresses per container.
  Address=0.0.0.0/28
  LinkLocalAddressing=yes
  DHCPServer=yes
  IPMasquerade=yes

• systemd-networkd running in the container configures the interface host0 inside the container based on the configuration below:

  [Match]
  Virtualization=container
  Name=host0
  
  [Network]
  DHCP=yes
  LinkLocalAddressing=yes

What happens instead:

• The host0 interface in the container never receives a DHCP configuration from the DHCP server running on the host because the requests/responses are blocked by firewalld on the host

Stopping firewalld temporarily "fixes" the issue and shows that firewalld is the "culprit" in this case.

Although I'm not quite sure yet, how the policy would have to look like exactly, I think this should be probably covered by firewalld's default configuration.

[t-woerner]

Only dhcpdv6-client is enabled by default in the firewall, as this is essential for mostly all clients using IPv6.
You can simply enable the dhcp service in your configuration to allow access to the dhcp server provided by systemd-networkd. If systemd-networkd is also providing a dhcpv6 server, then also enable dhcpv6.

[npmccallum]

The problem is that this breaks systemd-nspwan containers:
systemd/systemd#2552

The default policy needs to not break systemd on ve-* interfaces.

[sourcejedi]

I agree there's a conflict, but I'd like to note it goes beyond DHCP. Containers launched with systemd-nspawn -n are also intended to have internet access, e.g. for dnf.

(The default config for systemd-networkd enables ipv4 masquerading for this).

After allowing access to DHCP in firewalld, you get an address, but internet-bound packets are rejected as "administratively prohibited":

# traceroute 8.8.8.8   
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  gateway (10.0.0.1)  0.091 ms  0.031 ms  0.026 ms
 2  gateway (10.0.0.1)  0.033 ms !X  0.028 ms !X  0.028 ms !X

[SadPencil]

sudo firewall-cmd --add-service=dhcp

I think this issue could be closed.

[erig0]

The default policy needs to not break systemd on ve-* interfaces.

Firewalld upstream is not going to allow DHCP server by default. That can either be done statically by the distribution, or at runtime by the container startup.

After allowing access to DHCP in firewalld, you get an address, but internet-bound packets are rejected as "administratively prohibited":

Firewalld filters forwarded packets by default. You can add the container's interface to the trusted zone to remedy this.