how are we supposed to deal with multiple default routes? For example, when I add a new connection for a VLAN with nmcli, somehow another default route is being added. This most likely leads to connection problems and I have to delete the additional default routes to fix these problems.
IIUC there is supposed to be only one default route. However, it may get funny when I have multiple global IPv6 addresses on multiple interfaces all connected to different networks (VLANs). Since there is no NAT with IPv6, shouldn’t each of these interfaces have their own default routes as a direct way for the traffic to take?
And if I had multiple global IPv4 addresses, shouldn’t they each have their own default route as well?
The reason to have IP addresses in multiple different networks on a particular device is to be able to access these networks without having to send the traffic through the router (a gateway). That can be useful to unburdon the router from traffic, and for things like DLNA which are not so easyly usable across different networks.
For some of the networks a device is connected to, there is a gateway through which networks are reachable the device is otherwise not connected to. That means the device can reach the same networks through multiple gateways. For other networks a device is connected to, there is no such gateway.
It seems to make sense that traffic concerning a particular network the device is connected to would go through the gateway of that network when that’s possible and use another gateway when not in case that traffic needs to go to other networks. I’m not sure if that’s even possible to achieve.
What I do not want is to end up with broken connectivity because adding another connection has implicitly created another default route.
Why should I specify that access to local VLANs should be only used for local traffic when these VLANs are not only for local traffic? How would I specify that?
nmcli con add type vlan con-name pwnd dev br0 id 20 ip4 10.10.20.50/24 gw4 10.10.20.1 ipv4.ignore-auto-dns yes ipv6.ignore-auto-dns no ipv4.dns 127.0.0.1 ipv4.may-fail no ipv4.dns-search example.com ipv6.method auto ipv6.dns-search example.com ipv6.ip6-privacy 2
That gave me 2 additional default routes which I had to delete.
Shouldn’t network manager figure that adding these default routes breakes connectivity and at least give a warning or some advice instead of just adding more default routes?
Hm, ok, right, that was stupid of me. Maybe I’m confused today
I guess you can’t reasonably have multiple default routes and have to use static routes if you need to? If that’s the case, why doesn’t network manager give an error message when you try to create multiple default routes by adding connections?
Network Manager doesn’t look at your network holistically and make judgements about what you should and shouldn’t do. The connection you added was valid. There are situations in which you can add multiple gateways.
Thanks! I recreated the connection and that has left me with an IPv6 default route altogether. So I stopped and restarted the connection that usually creates the default routes, and there’s still not IPv6 default route. Maybe I need wait for router advertisements coming in to get it back?
What has not been mentioned is that there is actually a use for multiple default routes, and it was spoken of as OSPF routing in the past.
For example, you are at home and have a default route via your router/gateway that has a metric of 600. Now you start a VPN directly from your PC and it gets a new default route via the vpn with a metric of 100 (the original default still exists). Now the network traffic will be routed via the vpn until an attempt to reach some destination fails, in which case it falls back to being routed directly via the gateway network since the other path failed.
If you look at the metric value on each of those default routes they likely are different and it will attempt to use the one with the lowest metric value first then fall back in metric order until the connection succeeds.
The default route (and metric) does not matter if your interface is on a local network and communication is local, but does matter when it connects remotely via a gateway.
Hmm, interesting … I thought OSPF involved more than that. And how is determined if a destination can be reached so another route needs to be tried?
What I was wondering is about is more like using the “most direct” route. Image you have a web server connected to your router via multiple interfaces, and you have multiple internet connections. Now someone contacts your web server via one of the internet connections. Wouldn’t you want your web server reply directly from the IP address the client connected to rather than sending the replies via a different IP address because the web server has only a single default route? I never really thought about it because it’s all been IPv4 and NAT covers it all up anyway. But with IPv6, there is no NAT, and how is the server supposed to reply on the “most direct” route?
Same goes for different local networks (VLANs). I have firewall rules allowing devices on VLAN 20 to connect to some ports of my server which is in a different VLAN. Now the server is directly connected to that VLAN only because DLNA sucks. I still would rather not connect the server directly, but since it is connected now, it would be “more direct” for the clients to connect to the server directly. But they don’t do that because they have to use the IP address the server has in the other VLAN, and I have to keep the firewall rules, and I don’t want to run a name server for each VLAN to give different IP addresses to the clients depending on in which VLAN they are.
It’s working, but I’m not happy with this setup … The server shouldn’t need to be connected to that VLAN directly.
Metric determines preference order. Another route is selected if destination connection times out.
How the web server replies is material once the connection is made.
The client always expects replies from the IP it connects to. The server should always reply via the interface/ip where it received the incoming connection. This may be broken if you have one interface on the subnet with the address the server listens on and a different one with the main route for that subnet since now the reply comes from one IP/MAC pair while the initial connection is on another IP/MAC pair. VLANs with their own routes may help there.
VLANs allow further segmenting of subnet traffic even when using the same physical lan and interfaces. How you use that is “what works for your needs”.
There is a lot more complexity than we have space or time to discuss here.