Re: Multihomed server issue

["Jason A. Donenfeld" <Jason@zx2c4.com>]

Hi Wang,

Did you have any luck reproducing this with the netns.sh script?

Here's what's happening here:

1. Packet from peer P arrives from src:A dst:B
2. WireGuard records that it should contact P at src:B dst:A
3. When sending an encrypted packet to P, it asks for which interface
to use for src:B dst:A. The routing API returns interface I.
4. We ask whether interface I has an address B assigned to it. If yes,
we transmit the packet as src:B dst:A using interface I, and return.
If no, we move to step 5:
5. We ask which interface and src IP we should use for src:default
dst:A. The routing API returns interface I' (which may be the same as
I or perhaps not) and a default src address, B', for interface I'.
6. We transmit the packet as src:B' dst:A using interface I'.

In the past, this has been sufficient for handling issues with
multihomed servers, while still dealing gracefully with IP address
changes.

It seems like the problem you're facing is that B does not belong to
I, because B belongs to an unrouted dummy0 interface. The solution
would be to change the question of step 4 to instead ask if _any_
interface contains B, not just the returned interface I. While this is
essentially what's done for IPv6, I'm not certain this is the correct
behavior for IPv4. Do you know of any relevant RFCs for your use of v4
dummy interfaces and RTS routing? Or some other reference?

Please do let me know whether the above is an accurate representation
of the problem you're facing.

Jason