Re: Multihomed server issue

[Wang Jian <larkwang@gmail.com>]

2017-08-01 11:06 GMT+08:00 Jason A. Donenfeld <Jason@zx2c4.com>:
> On Tue, Aug 1, 2017 at 4:01 AM, Wang Jian <larkwang@gmail.com> wrote:
>> 2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld <Jason@zx2c4.com>:
>>> On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian <larkwang@gmail.com> wrote:
>>>> The solution can be one of:
>>>>
>>>> 1. server can RTS (response to source), or can bind to arbitary
>>>> address for outgoing
>>>
>>> The server does already respond to source.
>>
>> Sorry, I didn't make it clear. By saying RTS, I mean response to
>> source link, that is,
>> using called address and incoming link.
>
> You're still unclear to me. What?

Let's say server has multiple interfaces, eth0, eth1, ... ethN, with
IP0, IP1, ... IPn,
If an incoming request is to eth1, to IP1, then the server's response
packet will go out from eth1, and source is IP1.

In some cases, it can be done using policy routing, but other cases not. I know
a FreeBSD based VPN implements so called RTS.

In my case, the server looks like

eth0 = 10.1.1.2/24                    (default route, via 10.1.1.1/24)
eth1.100 = 172.16.1.2/30         (policy routing: when source address
is 111.111.1.0/24,  route via 172.16.1.1/30)
eth1.200 = 172.16.2.2/30         (policy routing: when source address
is 111.111.2.0/24,  route via 172.16.2.1/30)
dummy0 = 111.111.1.2/24
dummy1 = 111.111.2.2/24

When a wireguard client contacts 111.111.1.2, the server responses UDP packet
with source address 10.1.1.2 but not the desired 111.111.1.2, because
of default route.

I have mailed you my network setup privately. Sorry for inconvenience.