Certainly not. However, I see how you might think that: the code base and design is deliberately small and readable. It's very far from being a toy, but it aims to be as auditable as a toy would be.
I was confused about this too, but it made sense when I saw it another way. The network/IP address you put there is also added into the routing table, so it routes traffic to that network via the wireguard interface to the specific endpoint using the key associated with the destination address. While it might seem it doesn't have an important place in the receiving side (which I believe it does, especially when you have multiple hosts sharing a key), I feel it vastly simplifies things. You wouldn't have to worry about where a packet is getting routed if you look at the output of `wg` (if you keep the ACL minimal)
When the config is used with wg-quick(which you can setup as a service with systemd), it adds the address to the routing tables automatically and is less work for you to do.
>If WireGuard is as easy to set up as SSH, why not use SSH
Because SSH can't do many things that WireGuard can, and also speed. Especially since I believe it will get merged into the kernel. AFAIK Greg Kroah-Hartman is all for it[1], so I don't think it'll have any trouble.
Also, I'm interested in what you consider a 'real' VPN is. What do you think this cannot do, compared to say, OpenVPN?
[1]: https://plus.google.com/+gregkroahhartman/posts/jD6N4BzToa3
* Certificate management
* VLAN assignment
* LDAP, RADIUS
* Layer 2 bridging
* Multi-platform
* App deployment
* Host check
* NACLs
* DMZ
* HA
* Web UI
* TAP or TUN
* Stats, Reporting
* Scripted extensions
* APIThis is no guarantee; he was all for AF_DBUS / kdbus and that never happened.
I think what convinced me at least was the argument that larger codebases like IPSec were merged into the kernel, so why would WireGuard have any trouble?
Of course someone upstream might just decide to say no, and we'll have to live with the kernel module which is just as fast especially since it tends to reach line rate.
When sending; a single interface may have many peers configured. In that case WG needs to be told which peer to tunnel the packet to or it wouldn't know. It's can be viewed as WG internal routing table, in addition to the ordinary IP routing table.
When receiving; although the packet is proven to be from a configured peer, that peer may have used any IP as a source (referring to the encapsulated traffic). Even if you trust all your peers are who they should be this is a potential security risk. For example a peer may spoof its source IP to imitate another peer. You could patch this hole with iptables rules, but this way is more convenient and has a better chance of being correct since it's simpler to configure.
If you don't want any of this I suppose you could just set up multiple WG interfaces instead, configuring only a single peer for each interface and setting AllowedIPs to 0.0.0.0/0. That should give you the same behavior as a what I think you mean by "real VPN".
SSH supports a wider array of features while having effectively the same cost in implementation and use. The only difference is SSH doesn't support dual IP roaming and IP over UDP. Probably didn't need to start a whole new project when they could have added this to SSH, but then crypto nerds couldn't reinvent the wheel (and SSH probably wouldn't accept the patches).
And this baffles me:
"In the server configuration, each peer (a client) will be able to send packets to the network interface with a source IP matching his corresponding list of allowed IPs. For example, when a packet is received by the server from peer gN65BkIK..., after being decrypted and authenticated, if its source IP is 10.10.10.230, then it's allowed onto the interface; otherwise it's dropped." "system administrators do not need complicated firewall extensions, such as in the case of IPSec, but rather they can simply match on "is it from this IP? on this interface?", and be assured that it is a secure and authentic packet."
If this is on a dedicated tun/tap interface, shouldn't it only be transmitting secure and authentic packets anyway?? Why is IP traffic on an interface just assumed to be authentic information, if for example you aren't sure what put that packet on that interface? And you still need firewalls, so this duplicates configuration. This is basically an .rhosts file for a VPN.
If WireGuard is as easy to set up as SSH, why not use SSH? Because you want a VPN. But if you want a VPN, don't you want VPN features? WireGuard doesn't have VPN features. So you have to get a real VPN, or use SSH.
To put it another way: if you only want roaming IP and public keys, use WireGuard. For any other use case, you're going to get a real VPN or use SSH.