A multi-homed Linux server holds several IP addresses, and connections it initiates arrive at the peer carrying an unexpected source address. How does the kernel choose the source address for a locally generated packet, and how can you pin it?

## Why the question comes up at all A server with one address has no ambiguity. Add a second address, a second NIC, a VPN interface or a container bridge, and outbound connections suddenly start arriving somewhere with a source address nobody chose deliberately. This matters because peers frequently care: firewall allow-lists, database host rules, API allow-lists and audit logs all key off the source address. The traffic reaches its destination and is rejected there, which sends people hunting through firewalls when the fault is a routing attribute at home. ## The selection order For a locally generated packet the kernel resolves the source address like this: **1. An explicit bind wins.** If the process called `bind()` on the socket with a concrete address before connecting, that address is used and no selection happens. Many clients expose this — `curl --interface`, `ssh -b`, and a bind-address setting in most client libraries all end up here. **2. The route's preferred source.** The routing decision comes next, and the winning route may carry a preferred-source attribute, rendered as `src` in the table: ``` 192.168.1.0/24 dev eth0 proto kernel scope link src 192.168.1.50 default via 192.168.1.1 dev eth0 src 192.168.1.50 metric 100 ``` The kernel-generated connected routes get one automatically from the address that created them. Routes you add by hand do not, unless you say so. **3. Otherwise, an address of the egress interface.** With no preferred source the kernel picks an address configured on the outgoing device, preferring one whose scope suits the destination and, where possible, one in the same network as the nexthop. Crucially it prefers a **primary** address. When you add a second address in the same subnet as an existing one, the kernel marks it *secondary*, and secondary addresses are not chosen for source selection — which is why adding an extra IP to a NIC does not change how the box appears to the world. Because step 3 depends on the egress interface, changing routing changes identity. Bring up a VPN or a policy rule that steers traffic out of a different NIC, and the source address changes with it even though nothing about the socket changed. ## Seeing the decision `ip route get` answers all three parts of the routing decision at once: ``` $ ip route get 203.0.113.5 203.0.113.5 via 192.168.1.1 dev eth0 src 192.168.1.50 uid 1000 ``` Nexthop, egress device, and the source address the kernel would stamp on the packet. You can also test a hypothetical: `ip route get 203.0.113.5 from 10.0.0.7` asks what would happen for a packet already carrying that source, which is how you check policy rules that select a table by source address. ## Pinning the source address There are three levers, in decreasing order of bluntness: - **Bind in the application.** The most precise, because it affects only that process. Preferred when one service must present a specific identity and the rest of the box should not change. - **Attach `src` to the route.** `ip route change default via 192.168.1.1 dev eth0 src 192.168.1.60` makes every unbound socket taking that route use 192.168.1.60. Machine-wide for the destinations that route covers, and invisible to application code — document it, or the next engineer will not find it. - **Policy routing.** When traffic must leave a *different* interface depending on its source, source selection alone is the wrong tool; you need routing rules that select a separate table. That is a different mechanism from the `src` attribute, which only labels packets on a path already chosen. A fourth approach, rewriting the source address as the packet leaves, exists in the firewall layer, but for locally generated traffic it is a heavier and more surprising instrument than simply setting the route attribute. ## The IPv6 wrinkle IPv6 hosts routinely hold several addresses at once — link-local, a stable global address, and often temporary privacy addresses. Selection there follows the standardised rules of RFC 6724, which prefer, among other things, matching scope, a source whose prefix shares the longest match with the destination, and temporary addresses over stable ones for outbound connections when privacy extensions are active. That last preference is a common surprise: an IPv6 server whose peer allow-lists its stable address sees connections arrive from a rotating temporary one until privacy extensions are turned off for that interface. ## The habit to build When a peer complains about an unexpected source address, do not start with their firewall. Run `ip route get <their address>` on the sending host. The `src` field in that one line usually explains the whole ticket.