3 ms·

Thanks for being here, I have a few questions. Does the server get a separate wg interface for every client that connects? Or does it do something like multipo

by clinta 10y ago

Thanks for being here, I have a few questions. Does the server get a separate wg interface for every client that connects? Or does it do something like multipoint GRE interfaces with next hop addresses in the arp table? Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? Also is it in the scope of this project for peers to discover each other for direct communication, like a Phase3 DMVPN?

zx2c4 10y ago
> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? It uses a 1-RTT ECDH key agreement based on the Noise Protocol Framework, with identity hiding, perfect forward secrecy, and so forth. So, it does what you hoped it does. :) > Phase3 DMVPN I'm not familiar with this, but I'll read up on it. Just found a large cisco document describing it. I suspect that "automatic discovery" wouldn't be very much to my taste, but I'll read up on it before dismissing it wholesale.
- clinta 10y ago
  The idea of Phase3 is that you have multiple node routers connected to a VPN hub. Think branch offices. When one node starts to talk to another node, the Hub initially facilitates the traffic, but it sends a NHRP(Next Hop Resolution Protocol) packet to the nodes telling them the public IPs of eachother, the nodes then negotiate their own VPN tunnel and start communicating directly without passing all traffic through the hub. If I understand wireguard correctly it seems NHRP could be run using wiregard for transport, but it would cool if a separate NHRP daemon wasn't required, especially since wiregard is already tracking the mapping of internal to public IPs.
  - derefr 10y ago
    Just as a dumb spectator: that sounds a lot like https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab..., but below the application layer. Neat!
- Corrado 10y ago
  DMVPN capability would be outstanding and would make WireGuard much more useful in a AWS VPN situation. This video from the 2015 AWS re:Invent [0] conference has an overview of DMVPN and how it could be used in a AWS VPC. 0: https://youtu.be/ykmqjgLdmL4?t=53m20s https://youtu.be/ykmqjgLdmL4?t=53m20s
- dfrey 10y ago
  >> Does the server get a separate wg interface for every client that connects? > No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. Does this mean that it is impossible for two clients to connect to the same VPN server from behind router doing NAT? Or does each client choose a random source port for their traffic and then the combination of source port and source IP identifies the client?
  - zx2c4 10y ago
    The client is identified by the public key only. Two clients behind the same NAT can connect to the same server, no problemo.

by clinta 10y ago

zx2c4 10y ago

> Does the server get a separate wg interface for every client that connects? No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. > Does this do a DH key agreement to guarantee forward secrecy or does it literally encrypt the packet with the peers public key? It uses a 1-RTT ECDH key agreement based on the Noise Protocol Framework, with identity hiding, perfect forward secrecy, and so forth. So, it does what you hoped it does. :) > Phase3 DMVPN I'm not familiar with this, but I'll read up on it. Just found a large cisco document describing it. I suspect that "automatic discovery" wouldn't be very much to my taste, but I'll read up on it before dismissing it wholesale.

clinta 10y ago
The idea of Phase3 is that you have multiple node routers connected to a VPN hub. Think branch offices. When one node starts to talk to another node, the Hub initially facilitates the traffic, but it sends a NHRP(Next Hop Resolution Protocol) packet to the nodes telling them the public IPs of eachother, the nodes then negotiate their own VPN tunnel and start communicating directly without passing all traffic through the hub. If I understand wireguard correctly it seems NHRP could be run using wiregard for transport, but it would cool if a separate NHRP daemon wasn't required, especially since wiregard is already tracking the mapping of internal to public IPs.
- derefr 10y ago
  Just as a dumb spectator: that sounds a lot like https://en.wikipedia.org/wiki/Interactive_Connectivity_Establishment https://en.wikipedia.org/wiki/Interactive_Connectivity_Estab..., but below the application layer. Neat!
Corrado 10y ago
DMVPN capability would be outstanding and would make WireGuard much more useful in a AWS VPN situation. This video from the 2015 AWS re:Invent [0] conference has an overview of DMVPN and how it could be used in a AWS VPC. 0: https://youtu.be/ykmqjgLdmL4?t=53m20s https://youtu.be/ykmqjgLdmL4?t=53m20s
dfrey 10y ago
>> Does the server get a separate wg interface for every client that connects? > No. Each wg interface has a public/private key. It then has a list of peers' public keys and associated allowed IPs. By tying each public key to the allowed IPs of that public key, you can be sure that if a packet comes from wg0 and comes from a particular src IP, it comes from who you want. So no need for a new wg0 for each peer. Does this mean that it is impossible for two clients to connect to the same VPN server from behind router doing NAT? Or does each client choose a random source port for their traffic and then the combination of source port and source IP identifies the client?
- zx2c4 10y ago
  The client is identified by the public key only. Two clients behind the same NAT can connect to the same server, no problemo.