[WireGuard] Fwd: WireGuard cryptokey routing

* [WireGuard] Fwd: WireGuard cryptokey routing
       [not found]         ` <CAHmME9qr2H=4Qdzx9Kz4=op-O-yzum0+hJWvazHZ_K7ex05ncQ@mail.gmail.com>
@ 2016-07-05 16:34           ` Jason A. Donenfeld
  2016-07-05 18:05           ` [WireGuard] " Norman Shulman
  1 sibling, 0 replies; 12+ messages in thread
From: Jason A. Donenfeld @ 2016-07-05 16:34 UTC (permalink / raw)
  To: Norman Shulman, WireGuard mailing list

[-- Attachment #1: Type: text/plain, Size: 3732 bytes --]

Hi Norm,

I'm moving this discussion over to the mailing list. Please be sure to keep
wireguard@lists.zx2c4.com CC'd in your replies if you'd like a response.

Our prior conversation follows below.

Regards,
Jason

Forwarded conversation
Subject: WireGuard cryptokey routing
------------------------

From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 5:58 PM
To: team@wireguard.io

You state:

"
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
"

But the allowed IPs can be non-routable addresses, so they are not
necessarily unique.

----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:09 PM
To: Norman Shulman <norman.shulman@n-dimension.com>

Hi Norman,

Can you expand what you mean a little bit by "not necessarily unique"?
And why that matters? I'm not sure I understand the thrust of your
point.

Thanks,
Jason

----------
From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 6:14 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>

Hi Jason,

Many clients use the non-routable 192.168.0.0/16 addresses. How can looking
up such an address identify the client?

Thanks.

Norm

----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:19 PM
To: Norman Shulman <norman.shulman@n-dimension.com>

Hi Norm,

I think you're misunderstanding how things work. I'll try to explain a
bit more clear here:

A linux system has several network interfaces, such as lo, eth0,
wlan0, wg0. The ordinary kernel routing table determines which
interface to use when sending outgoing packets. So, let's say the
kernel routing table is setup to route 192.168.0.0/16 via WireGuard:

# ip route add 192.168.0.0/16 dev wg0
or
# ip addr add 192.168.0.5/16 dev wg0

Now userspace can send packets that will be handled by the wireguard driver:

# ping 192.168.32.19
...

When that ping packet hits the wireguard driver, it has a dst IP of
192.168.32.19. What does wireguard do with it now?

It looks in the cryptokey routing table to see if 192.168.32.19
belongs to any peers. If so, it uses that peer's public key to make a
secure session and encrypt that ping packet. It then sends it off to
the peer's configured external internet endpoint.

Does this make more sense? Or is there still something you're wondering
about?

Regards,
Jason

----------
From: *Norman Shulman* <norman.shulman@n-dimension.com>
Date: Tue, Jul 5, 2016 at 6:23 PM
To: "Jason A. Donenfeld" <Jason@zx2c4.com>

Hi Jason,

I'm still wondering what wireguard does if more than one peer has the
address 192.168.32.19.

Thanks.

Norm

----------
From: *Jason A. Donenfeld* <Jason@zx2c4.com>
Date: Tue, Jul 5, 2016 at 6:30 PM
To: Norman Shulman <norman.shulman@n-dimension.com>

Hi Norm,

If you run these commands:

wg set wg0 peer ABCD allowed-ips 192.168.32.19/32
wg set wg0 peer EFGH allowed-ips 192.168.32.19/32

After the first command ABCD has 192.168.32.19/32. After the second
command, ABCD has no allowed ips, and EFGH has 192.168.32.19/32.

However, if you run these commands:

wg set wg0 peer ABCD allowed-ips 192.168.32.0/24
wg set wg0 peer EFGH allowed-ips 192.168.32.19/32

After running both commands, ABCD will have 192.168.32.0/24 and EFGH
will have 192.168.32.19/32. However, when sending packets, the routing
table lookups will always match on the most specific match, so ABCD
will not be able to send or receive packets for 192.168.32.19/32.

Make sense?

Jason

[-- Attachment #2: Type: text/html, Size: 7234 bytes --]

^ permalink raw reply	[flat|nested] 12+ messages in thread