** Changed in: systemd
Status: Unknown => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1835581
Title:
networkd-dhcp4 does not set prefsrc for dhcp-provided classless or
static routes
Status in systemd:
Fix Released
Status in systemd package in Ubuntu:
In Progress
Status in systemd source package in Bionic:
In Progress
Status in systemd source package in Cosmic:
In Progress
Status in systemd source package in Disco:
In Progress
Status in systemd source package in Eoan:
In Progress
Bug description:
[impact]
the systemd networkd dhcp4 client sets the prefsrc for the default
route added when a dhcp server provides only the gateway; but if the
dhcp server provides classless route(s), those are configured instead,
and the prefsrc is not set for those.
Normally this is ok, but if the dhcp client system has other
address(es) configured on the interface using dhcp, then the src for
packets sent through a classless/static route might not be the same as
the address provided by the dhcp server.
If the gateway/router provided in the dhcp classless/static route(s)
only allows traffic from the address provided to the dhcp client, then
traffic from the dhcp client may be dropped by the gateway/router.
[test case]
set up a dhcp server system (e.g. ubuntu with dnsmasq installed and
configured) and a dhcp client system. For example on the dhcp server,
use this dnsmasq config:
interface=ens8
bind-interfaces
domain=test,10.10.0.0/24
dhcp-option=42,10.10.0.1
dhcp-range=test,10.10.0.10,10.10.0.100,1h
On the dhcp client system, use networkd config such as:
$ cat /etc/systemd/network/80-ens8.network
[Match]
Name=ens8
[Network]
DHCP=ipv4
LinkLocalAddressing=ipv6
Address=10.10.0.5/24
Reboot the client, or restart networkd, and it should result in:
$ ip -4 a show ens8
3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
valid_lft forever preferred_lft forever
inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
valid_lft 3580sec preferred_lft 3580sec
$ ip r
default via 10.10.0.1 dev ens8 proto dhcp src 10.10.0.75 metric 1024
10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
10.10.0.1 dev ens8 proto dhcp scope link src 10.10.0.75 metric 1024
Note that, because networkd completes the static ip configuration
before the dhcp reply is returned and processed, the static address is
used for the subnet-local routing. But for global routing through the
gateway, the dhcp-provided address is used:
$ ip r get 1.1.1.1
1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.75 uid 1000
Now on the server, add a classless route:
dhcp-option=121,0.0.0.0/0,10.10.0.1
and restart dnsmasq on the server. Then on the client, reboot. It
should now have:
$ ip -4 a show ens8
3: ens8: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP
group default qlen 1000
inet 10.10.0.5/24 brd 10.10.0.255 scope global ens8
valid_lft forever preferred_lft forever
inet 10.10.0.75/24 brd 10.10.0.255 scope global secondary dynamic ens8
valid_lft 3585sec preferred_lft 3585sec
$ ip r
default via 10.10.0.1 dev ens8 proto dhcp metric 1024
10.10.0.0/24 dev ens8 proto kernel scope link src 10.10.0.5
Now, the global route will use the static address, not the dhcp-
provided address:
$ ip r get 1.1.1.1
1.1.1.1 via 10.10.0.1 dev ens8 src 10.10.0.5 uid 1000
If the router, 10.10.0.1, only will forward traffic sent from the dhcp
address it provided, 10.10.0.75, then this configuration will result in the
client being unable to reach anything through the router, because all its
packets will have a source address of 10.10.0.5, which the router would
drop/reject.
[regression potential]
this only affects dhcp routes provided by a dhcp server using the
'static' or 'classless' route dhcp options. Since this behavior is
currently the default when a system doesn't add static address(es) to
interfaces that also get dhcp addresses, this is likely not a change
in behavior for the vast majority of systems. And any systems that do
add static address(es) would usually be able to route through a
gateway from either the dhcp-provided, or static, address. So the
regression potential for this change should be low.
[other info]
TBD
To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1835581/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
