Multihomed server issue

Wang Jian larkwang at gmail.com
Thu Aug 3 05:00:51 CEST 2017


2017-08-01 19:28 GMT+08:00 Wang Jian <larkwang at gmail.com>:
> 2017-08-01 11:06 GMT+08:00 Jason A. Donenfeld <Jason at zx2c4.com>:
>> On Tue, Aug 1, 2017 at 4:01 AM, Wang Jian <larkwang at gmail.com> wrote:
>>> 2017-07-31 23:34 GMT+08:00 Jason A. Donenfeld <Jason at zx2c4.com>:
>>>> On Fri, Jul 28, 2017 at 2:51 AM, Wang Jian <larkwang at 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.

I managed to handle this issue for one public address

------
[Interface]
FwMark = 600
PostUp = ip rule add pref 20000 fwmark 600 table 600; ip route add
table 600 default via 172.16.1.1 src 111.111.1.2
------

With this workaround, for a wireguard interface, only one public address can
be used. We do need multiple public addresses for a reason: some clients
connect to one public address while other clients connect to another public
address.

We can use multple wg interfaces to address the limitation. But I do wish that
server can deduce public address which the client connects to, and use the
public address to response to the client, then the configuration will be
simple and straightforward.


More information about the WireGuard mailing list