MULTI: bad source address from client: Whose Address Was It?
The inner source does not match the client that delivered it. Match it to a tunnel assignment, a LAN behind the client, or a duplicate identity.
The server log prints MULTI: bad source address from client, drops the packet, and the session stays connected. That combination confuses people who read the message as an authentication failure. It is not: the client authenticated, and the packet that arrived carried an inner source address the server could not associate with that client instance. The check happens before delivery, which is why the tunnel looks healthy while nothing useful crosses it.
What the server compares before delivery
For each packet arriving from a client, the user-space server looks at the source address inside the tunnel and asks its internal routing state which client that address belongs to. If the owner is a different instance, or no owner at all, the packet is cleared and the warning is emitted.
Ordinary delivery through the tunnel interface never happens.
That ordering explains a detail people find baffling: the host firewall's counters do not move, because the packet never reached the firewall. Adjusting reverse-path filtering on the host changes nothing here, since the rejection happened in the daemon's own association check. Read the message as a statement about ownership, then find out which of three situations produced it.
Three sources of a mismatched inner address
The client may be sending from an address it was not assigned, from a network nobody declared as belonging to it, or from a duplicate of an identity that already has an owner. All three produce the same log line. They differ in what you have to change. Start with the address and the current assignment list, and let those two facts pick the case.
Telling those apart takes two facts: the rejected address in the log, and the assignments the server believes are current. The second is available from the status or management view of the running instance, and it is the only authority worth consulting, because a configuration file records intentions rather than the present state.
Record both before you change anything, then classify. A screenshot taken afterwards is not a record of the state that produced the warning. Keep the timestamp as well, because assignments move between sessions.
| Rejected source is | Likely cause |
|---|---|
| The client's own tunnel address | Static assignment conflict, wrong profile, or manual address change |
| A host behind that client | Missing internal ownership for that prefix |
| An address belonging to another session | Two devices sharing one identity or one static address |
The LAN behind a client and iroute
When a site client routes its own private network, that network has to be declared as belonging to the client. A client-specific file with an iroute entry does that, and the entry names the prefix the client is allowed to carry.
A kernel route pointing the same prefix at the tunnel is a separate requirement, and adding it changes nothing about the daemon's internal ownership.
# /etc/openvpn/server/ccd/site-b
iroute 192.168.70.0 255.255.255.0Confirm the effective identity matches the filename, since a mismatch means the file never loads and the symptom is identical to a missing entry. Do not add a broad iroute to silence the warning, because that converts an unexpected source into an authorized one without answering why the client sent it. The OpenVPN 2.6 manual documents iroute, duplicate-cn and identity mapping as separate controls.
The same identity on two machines
A profile copied to a second laptop carries the same certificate and the same common name. Depending on the server's settings, the newer connection can replace the older one, and whichever instance holds the ownership wins the association check.
That makes the fault look intermittent, appearing only when both devices are awake.
Allowing duplicate common names lets both connect, but it does not give them independent static addresses or independent ownership. If two devices must coexist, enrol them separately so each has its own identity and its own assignment. Treating the duplicate setting as a repair for this warning leaves the mystery in place and adds a second one.
Prove the association changed
Apply the correction through the configuration owner, then reconnect the affected client so the new policy loads.
Repeat the same flow and confirm three things: the packet's inner source, the client instance the server associates with it, and the destination behaviour afterwards.
If the warning stops but the application still fails, the problem moved rather than vanished. Forwarding, firewall rules and the return path are separate stages, and passing the association check only means the packet was allowed to leave the tunnel.