Let’s talk
← All insights
ENGINEERING JOURNAL / Linux Operations

NetworkManager Routes: Explain the Chosen Default Path

Investigate a Linux host using the wrong outbound interface by comparing active routes, connection profiles, metrics and persistent default-route intent.

Clouvenix Engineering notes · 3 min read · 20 Oct 2026
NetworkManager Routes: Explain the Chosen Default PathNetworkManager Routes: Explain the Chosen Default Path — conceptual 3D-style vector showing Application packet, Route lookup, Primary uplink, Secondary uplink, Connection profile, Destination.. Conceptual teaching illustration; connections show the investigation flow rather than a vendor deployment topology.CLOUVENIX / LINUX OPERATIONSNetworkManager Routes: Explain the Chosen Default Path01Application packet02Route lookup03Primary uplink04Secondary uplink05Connection profile06DestinationConceptual investigation flow / NetworkManager Routes: Explain the Chosen Default Path
NetworkManager Routes: Explain the Chosen Default Path — conceptual 3D-style vector showing Application packet, Route lookup, Primary uplink, Secondary uplink, Connection profile, Destination.

Context

A server with two network interfaces begins sending outbound traffic through the management network. Both links can be healthy while the chosen route is wrong for the application's design. NetworkManager stores persistent connection profiles, and the kernel uses active routing state. Those two views should be compared before changing a gateway.

Prepare the host's interface map, intended primary path, management access method and a known destination address. Have console recovery available before applying network changes remotely. The commands here inspect state; reconnecting a profile or altering routes can interrupt the very session used for administration.

Inspect destination-specific routing

  1. Run ip route show and, where relevant, ip -6 route show. Record default routes, metrics and interfaces. Then use ip route get 203.0.113.10 with an appropriate real destination for your environment; the documentation address is only a placeholder. This asks about a particular lookup rather than assuming the first displayed default explains all traffic.
  2. Read nmcli connection show --active and inspect the relevant named profiles with nmcli connection show 'profile-name'. Compare gateway, ipv4.route-metric, ipv4.never-default and their IPv6 equivalents. A device can receive a DHCP gateway even when the operator remembers configuring only a static application address elsewhere.
  3. Inspect routing rules with ip rule show when source-specific paths or multiple routing tables are part of the design. An application's selected source address, a more specific route or a policy rule can override expectations based on a default-route metric alone. Compare the failing application's destination and source with a working administrative probe.

An illustrative profile surprise

In an illustrative backup server, a newly activated management connection receives a DHCP default route with a preferable metric. Backups then traverse a smaller management uplink. Deleting the active route manually fixes one test but the route returns on reconnect. The persistent profile's routing intent must be corrected, and IPv6 behavior needs a separate review if enabled.

ObservationDiagnostic viewPossible explanation
Wrong default returns after reconnectNetworkManager connection profilePersistent automatic route
One destination differs from othersip route get and specific routesMore specific match
Source address changes resultRouting rules and tablesPolicy-based selection
IPv4 fixed, some clients still failIPv6 routes and application preferenceSeparate address-family path

Correct the intended routing policy

If a connection must never supply a default route, evaluate its documented never-default setting. If it is a deliberate fallback uplink, a reviewed metric may express preference more accurately. These choices have different meanings: a high metric keeps a candidate route, while forbidding a default removes that role from the connection.

Apply a narrow profile change through the environment's tested procedure, preserving the prior profile and recovery path. Validate it on a console or equivalent safe connection. Retest destination lookup, actual application traffic and management reachability. A successful ping alone does not verify a stateful application's source address or return path.

Document route ownership

Keep a connection-to-network-role map and record whether DHCP may introduce gateways. Monitor unexpected default-route changes and critical outbound transaction success. Recheck profile behavior after network restarts during a planned window, because persistence is part of acceptance. Clouvenix Linux administration can help make multi-interface routing choices explicit in the server SOP.

Technical reference

NetworkManager connection settings and IP configuration properties.