[Impact]
This tends to break network connectivity to specific hosts if such hosts were accessed before a change in network topology.
Specifically:
- User pings a system;
- User tries to connect to that system with SSH, it fails and the user realises they are not connected to a VPN required to reach that device.
- User connects to the VPN
- System is still unreachable because it is listed as reachable via the original network device rather than the new VPN-created network device.
Or; the user changes from wired to wifi and loses connectivity to some systems because they were initially accessed over wired and the IPv6 route remains via the old device.
[Test Case]
Requires a valid IPv6-enabled network.
1) Connect to an IPv6 network.
2) Ping Google via ipv6: 'ping6 ipv6.google.com'
3) Observe whether 2607:f8b0:400c:c03::6a gets added to the IPv6 routing table:
'ip -6 route'
Without the patch, any host that gets packets sent to it will be added to the routing table; with the patch, such hosts are not listed in the routing table with the 'ip -6 route' command.
[Regression Potential]
Risk is minimal; the messages processed are not meant to be received by NetworkManager. A possible regression scenario would be if valid netlink messages for new routes would be generated by the kernel with the RTM_F_CLONED message when they indicate new network routes required due to a topology change, rather than new temporary cache routes for accessing a particular host; and would cause the new route to not be added (causing limited network unreachability).
---
Any time an IPv6 route lookup happens, the kernel generates a new routing cache entry and notifies userspace using a netlink "new route" message with the RTM_F_CLONED flag set on the route.
Network Manager doesn't check for this flag, so it accepts it as a new real route and adds it to its internal route cache. Then, because the event triggers an interface update, it synchronizes its route cache with the kernel table, putting the cache entry in as a real host route.
I think NM might also overwrite the next hop of the route based on its internal idea of the default route, but I'm not sure.
This causes problems if you have interfaces not managed by NetworkManager, such as manually configured VPNs, since these host routes override the route entries that send traffic down those interfaces rather than to the default router.
To reproduce:
Ensure "Ignore automatically obtained routes" is unchecked in Edit Connection -> IPv6 -> Routes, because this blocks the last stage (copying the spurious route back to the kernel).
Connect to an IPv6 network.
run `ip -6 route` and observe no extra routes
run `ip -6 route get 2600::`
run `ip -6 route` again and observe the new static route to 2600:: via your default gateway
Expected behavior:
No changes to routing table due to a route lookup.
Patch attached that checks whether a new route notification is for a route cache entry, and if so, ignores it. Solves the problem for me, but I haven't checked for regressions or more complex use cases.
Diff is against 0.9.4.0-0ubuntu4.1.