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 <[email protected]> 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
