Aside from the cryptorouting concept and some convenience functions in wg-quick, Wireguard doesn't really have strong opinions on routing. It's perfectly legitimate to setup an interface with a single peer and global (0.0.0.0/0, ::/0) routes then use BGP to announce networks across it and manage the kernel route tables.
> 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.
You can just set your peers on separate wg interfaces. At least on Linux, you have tables to control routing before packets reach the interface.
So you can have two wg interfaces, each with a single but distinct peer both with CIDR 0.0.0.0/0 (or what have you), and use ip-route/nftables as usual to pick the appropriate outgoing interface.
But yeah, me saying it "does no routing" was not really correct. But that routing happens after that of the (rest of the) Linux kernel, not overlapping with, replacing, or conflicting with.
One thing worth adding to this is that what wg-quick does here - adding routes for each entry in AllowedIPs and a corresponding routing policy - is not part of wireguard itselfbut a wg-quick specific thing.
This can become important if you want to have redundant gateways or something like that - you can have overlapping AllowedIPs, it just won't work out of the box with wg-quick.
For example, systemd-networkd started also adding routes by default in v250 but (rightly so IMO[0]) reverted to not doing it in 250.3.
Wireguard is a great solution for a secure, high-performance data pipe. However, it only supports layer 3 static routing by itself, which by itself fits none of my typical use cases.
If you're willing to think of it as a secure control plane where the cryptographic identities of peers are mapped to IP addresses, you can run other tried-and-tested but insecure tunnels over it.
I don't believe this is something wireguard cares about. It looks like they're aiming for doing in-kernel build-your-own routing VPN solution for servers where the networking is completely within your control. If you need a solution for privacy / working around provider limitations, then other software may be better.
This is less important although useful in some cases. The more important thing is outbound - since Wireguard is layer 3, in the routing table you can't specify a peer to send the packet to like you can with ethernet, and it has to choose one using AllowedIPs.
If you haven't picked it up from context: Wireguard is a VPN that provides a virtual network interface (wg0, wg1...) which can be routed, firewalled, and so forth.
Notable bits: very little code, so it's easy to audit. Very few options, so it's easy to get it do what it does. Very simple config, as a result of the very few options.
Basically, take all the things which drive people crazy about IPsec (all the options, all the choices, the difficulty of debugging, the multiphase negotiations, the usual policy routing rather than interface routing) and make them go away by not just choosing reasonable defaults but not even providing the capability to make different choices.
Almost every problem I've seen someone have with WireGuard comes down to one of two things:
1. They misunderstand what AllowedIPs actually does
2. They don't understand networking.
WireGuard is _incredibly_ simple. Not easy. Simple. You configure your peering on each side, and what you end up with is--as far as userspace can tell--a perfectly normal layer 3 interface. You are then free to configure your firewall rules and route tables however you like in order to achieve your goals.
If you understand networking (and how to perform network configuration on Linux), then this is a powerful tool.
If you don't understand networking, then you end up writing posts like this.
The thing about Wireguard is that it's very simple and minimal. It does just one thing, and that is - establishes a layer 3 tunnel for sending IP packets between local machine and some other peers. It doesn't do mesh, it doesn't do routing (it just knows the IPs of its direct peers and that's all it does), it doesn't do bridging - all this stuff is done by other pieces such as Linux kernel, but not Wireguard itself.
> Wireguard walk-through to bridge two separate LANs
Same or different subnets for those LANs? If they're different and non-intersecting, and if you don't need cross-LAN broadcast or multicast, the simplest option is to establish a Wireguard connection between those LAN's default gateway routers (assuming you can do this), and on each of those routers set up a route that sends opposite LAN's traffic to the opposite gateway (in case of iproute2: `ip route add my.other.lan.subnet/mask via my.other.lan.gw`, how to make this persistent depends on your distro). Then, on each gateway, allow packet forwarding between Wireguard and LAN interfaces (with e.g. iptables or nftables or whatever you use there).
If you can't run Wireguard on gateways, the overall principle holds, but you'll need to distribute routes to your respective LANs via Wireguard-running routers through DHCP or whatever you use for routing on your LANs (e.g. OSPF).
And if your LANs both have the same subnet, or if you need multicast, things get significantly trickier (plus, there's inevitable question of what should happen if two machines on different LANs have the same IP). You'll probably need to run something like L2TP or GRETAP (or something else that can encapsulate you layer 2) over Wireguard.
Or maybe just use OpenVPN in TAP mode (if you want all stuff independent of any third parties) or Tailscale (because it already works).
I think that people are looking for Wireguard to be something that it isn't. It's a fancy Ethernet cable, that's all. You can build a lot of neat things on top of Ethernet cables, like full networks. But it's not the cable that builds the network, it's just a low-level tool for facilitating that construction.
If you want to do something like make a point-to-point VPN, then wg-quick is that layer on top. If you want to build a mesh network from endpoints authenticated with a third-party identity provider, you want something like Tailscale. Wireguard is just a low-level building block that handles the crypto in those use cases; making something high-level is left as an exercise to the reader.
> You have to give it routing information through an out of band mechanism “AllowedIPs.” One downside is that you can’t have two peers that act as general routers on the same wireguard network
This is a common misconception, due to that this is the way wg-quick works (unfortunately IMO; presumably to make it easier, and I guess wg-quick was never meant for people with advanced needs). On a lower level, AllowedIPs is really just "allowed IPs", and does no routing. You can have multiple active peers with overlapping AllowedIPs.
If you set up the tunnel through other means, you can make your own routes.
For example in systemd-networkd, see `RouteTable` under the `[WireguardPeer]` section of systemd.netdev(5).
(This was unfortunately broken for a brief while in systemd in Jan, but should now be fixed again: https://github.com/systemd/systemd/pull/22136. If it's not clear from the link, old and current behavior are that no routes are added unless RouteTable is explicitly set)
You should also be able to set it up manually and then add routes, policies and rules manually however you would otherwise.
(You're of course right on the protocol layer, but that is not the cause of the problem you want to solve)
Routing is actually a layer before packets make it to the WireGuardNT miniport driver. Usually the routing table controls this, but WFP callout drivers can also steer traffic to specific adapters based on things like process image path or security descriptor. So for this functionality, WireGuardNT can be used with various WFP drivers or routing table configurations. It's not something that'd belong in WireGuardNT itself.
With regards to the WireGuard for Windows client, though, whether we'll put the time in to develop such a WFP driver and integrate it there I guess is still up in the air, like many feature wishlist items are.
>If this is on a dedicated tun/tap interface, shouldn't it only be transmitting secure and authentic packets anyway?
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?
Not OP. I do not have issues with WireGuard's cryptography.
I do have issues with wireguard's security - things like silently accepting invalid configuration, changing one peer can silently affect another (only avoided via external means), roaming is default enabled and can't be disabled nor can you bind the tunnel to an interface or an ip, nor does it pad packets even the slightest to reduce "meta"data leakage.
Just because the cryptography is (probably) sane, doesn't mean wireguard as a whole is good for all or most use-cases.
WG isn't just stable, it's so easy to configure and set up you'll wonder why you didn't do it ages ago. At least that's the way it was for me.
I stand by my assertion that eventually nobody will talk about Wireguard because everyone will use it for almost everything. It'll be like HTTPS, TLS, or TCP.
Not the OP, but the main problem with WireGuard[0] is not the protocol[1], it's good, but the opinionated tooling around it, be it .INI style configurations (god I hate it), mutual incompatibility of wg and wg-quick or just outright stupid decisions around storing config files and interacting with the user in the Windows client.
Though there are some nuances with the routing selection/filtering too, which gets troublesome when you just need a pipe and run a proper routing protocols over it. ::/0 solves most of it but still there are some rough edges.
[0] well, for *me*
[1] One of the amusing things I discovered what I have a full 10MB/s+ to the SMB server in the DC over the WireGuard tunnel (and that's because it's 100Mbit/s uplink), while the Synology which sits on the same router on a 1Gbit port only makes 3-5MB/s.
I've done a lot of professional work over the past few months† with WireGuard and can't think of a piece of information I've ever needed to troubleshoot it that it doesn't provide. You know about `dynamic_debug`, right?
There's also just not that much to debug! You've got keys, allowed IP lists, and endpoint addresses. There aren't a lot of other knobs to turn!
I think a thing that gets people into trouble with WireGuard is not understanding how modest its design is. The goal of WireGuard is to drop into the networking stack as just another interface. It doesn't intend to implement an entire new networking model on top of itself. My experience has generally been, if it's straightforward to express in the Linux networking model, it's straightforward with WireGuard.
I think this is a very good thing. I really don't want to have to think about what the OpenVPN developers believe about networking in general. I want to bring up secure transports and route packets over them the way I'd route over any other tunnel I want orthogonal, predictable interfaces that I (or Tailscale, or whatever) can build more complicated things on top of.
Not at all. See the links in the thread. You can try it yourself to verify if you do not believe me (and again, wg-quick does extra things here which are not inherent to Wireguard). And also again, you can specify as many wireguard interfaces as you want - no need to cram all peers into one interface.
> I did a vuejs/html5 web interface for wireguard recently and found it delightful to work with.
Sounds cool. Care to share? I'd love to see people's usage.
> - there is no option to specify listener ip+port tuples
WireGuard listens on all interfaces, because packets themselves are authenticated cryptographically. If a packet makes it to your system and the authtag is validated, it doesn't matter through what interface it arrived; it's legit. WireGuard also is able to reply using the destination address and interface of the incoming packet as the source address and interface of the outgoing packet, which is the other common usage of binding to particular IP addresses.
> - logical sub-interfaces work fine, unless they happen to emit a vlan tag
WireGuard is layer 3 -- IP -- not Ethernet, which is how I believe tunnels should be made. Instead of vlans, just add more tunnels if you need.
> - almost every virtual ethernet device in the kernel calls eth_hw_addr_random(dev);
WireGuard isn't Ethernet; it's IP. It doesn't use MAC addresses. It has public keys instead.
> - "allowed-ips" cannot be turned off;
Yes: the crypto key routing is the central idea of WireGuard. You establish a strong binding between public key and internal tunneled IP address, and then all your rules and policies on top of that suddenly become quite simple.
> - when one "allowed-ips" setting is added to a peer, wg may silently remove "allowed-ips" on another, unrelated peer
Peers can't share internal tunneled IP addresses; otherwise, there wouldn't be strong binding to public keys, nor efficiency of sending outbound packets. So if you assign an already assigned one to another peer, the presumption is that you want to _move_ the allowed IP. By always going with the newer future demand, and not erroring and staying with the old one, we ensure forward progress on your overall changes to policy. IOW, if you're changing things, we want the state to look like what you're changing it to.
If you have any additional questions at this level (a great level, thanks for those), a better place to discuss is probably #wireguard on Freenode, or the mailing list -- https://lists.zx2c4.com/mailman/listinfo/wireguard
reply