From: Samuel Holland <samuel@sholland.org>
To: Chris Osicki <wg@osk.ch>, Roman Mamedov <rm@romanrm.net>
Cc: Gijs Conijn <egc112@outlook.com>,
WireGuard mailing list <wireguard@lists.zx2c4.com>
Subject: Re: WG default routing
Date: Tue, 5 Jan 2021 19:17:29 -0600 [thread overview]
Message-ID: <9c84d905-f707-bdf1-edff-afb50e3da6e1@sholland.org> (raw)
In-Reply-To: <20210105211301.GC31054@server>
On 1/5/21 3:13 PM, Chris Osicki wrote:
> On Wed, Jan 06, 2021 at 01:25:30AM +0500, Roman Mamedov wrote:
>> On Tue, 5 Jan 2021 21:12:12 +0100
>> Chris Osicki <wg@osk.ch> wrote:
>>
>>> As far as I can see after few tests, AllowedIPs config file option has nothing to do with routing and I hope
>>> it will stay like this.
>>
>> wg-quick uses AllowedIPs to also set up matching entries in the system routing
>> table. This can be disabled in its config.
>>
>>> It is just a filter
>>
>> It is not only a filter on incoming packets, but also WG's internal routing
>> table for knowing which packets should be sent to which peer.
>
> I'm sorry to contradict you but after some more readig I have to :-)
> WG has no "internal routing table", wg-quick (which, BTW, is not the subject of my query) uses it to modify
Did you read this part of the home page?
https://www.wireguard.com/#conceptual-overview
At the heart of WireGuard is a concept called Cryptokey Routing,
which works by associating public keys with a list of tunnel IP
addresses that are allowed inside the tunnel.
[...]
In the server configuration, when the network interface wants to
send a packet to a peer (a client), it looks at that packet's
destination IP and compares it to each peer's list of allowed
IPs to see which peer to send it to.
[...]
In other words, when sending packets, the list of allowed IPs
behaves as a sort of routing table, and when receiving packets,
the list of allowed IPs behaves as a sort of access control
list.
WireGuard itself does indeed have an internal routing table. And you
should really read that whole section.
> kernel routing tables, from the wg-quick man page:
>
> It infers all routes from the list of peers' allowed IPs, and automatically adds them to the system routing
> table. If one of those routes is the default route (0.0.0.0/0 or ::/0), then it uses ip-rule(8) to handle
> overriding of the default gateway.
>
> So, in my test config I have a server, 10.10.10.1 and two clients, 10.10.10.2/3
> If on the server I remove the AllowedIPs option, no one can connect.
> Giving AllowedIPs = 10.10.10.0/24 both clients can connect and routing in them stays as it was.
> The same for the clients, without AllowedIPs = 10.10.10.0/24 cannot connect.
>
> Thus, my question still remains: why this filtering function?
Because, as the WireGuard website explains, a tight, static binding
between a peer's identity and its IP address range is an extremely
useful building block, both for security and for designing a network
topology.
Cheers,
Samuel
next prev parent reply other threads:[~2021-01-06 1:17 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-03 21:54 Chris Osicki
2021-01-04 13:22 ` Gijs Conijn
2021-01-05 20:12 ` Chris Osicki
2021-01-05 20:25 ` Roman Mamedov
2021-01-05 21:13 ` Chris Osicki
2021-01-05 23:50 ` Phillip McMahon
2021-01-06 1:03 ` Corey Costello
2021-01-06 1:17 ` Samuel Holland [this message]
2021-01-04 13:38 ` Henning Reich
2021-01-05 20:15 ` Chris Osicki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9c84d905-f707-bdf1-edff-afb50e3da6e1@sholland.org \
--to=samuel@sholland.org \
--cc=egc112@outlook.com \
--cc=rm@romanrm.net \
--cc=wg@osk.ch \
--cc=wireguard@lists.zx2c4.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).