Wireguard is L3, right? So it behaves like a network layer VPN. That means that you can't switch how traffic is flowing based on application protocol. But I'm not super familiar with VoIP stuff.
You can split the tunnel based on IP routing, but I think that's as good as it gets. So if you want to Wireguard specific traffic to your peer then you're fine. For instance, we have our internal cloud network linked to our offices via wireguard, but traffic to anything that is not that network goes to the public Internet via our fiber.
But if we wanted to send HTTP requests always through the WG, that is not possible to configure because WG acts as an L3 VPN and Layer 3 has no conception of anything but the network. You couldn't say "Send HTTP requests through my normal fiber, but DNS requests through my VPS peer".
Huh - I'm using Wireguard as my VPN into my home network (the only port that I have opened to the outside world), but I didn't know that you could also use it to route incoming requests to a certain VM. There's always something else to learn! Thank you :)
What you'd normally think of as Wireguard allows routes at connection time sure, however OP wants a VPN which allows peer B ("server") to define a route and advertise that route to peer A ("client"). So one day the client would route 10.1.0.0/24 down the wireguard tunnel, but not 10.2.0.0/24, the next day however from changing peer B, the config on peer A would change.
Obviously there are many things you could do to allow this (run a routing protocol, build a custom client which gets route information, etc), but the "out of the box" wireguard is a kernel interface, a wg command, and a utility script (wg-quick). I think there are some gui based clients for non-linux based OSes, but it's the same principle.
DNS is nothing to do with the wireguard kernel or userspace, it's configured in the "wg-quick script" (there's a bash function called set_dns), but you can do that however you want.
Wireguard alone isn't what an enterprise would consider to be a "VPN solution", it doesn't push configs from a central location, it's very much a peer-to-peer tool. You can build "enterprise" features like centrally defined routes or DNS on top of that, or not, it's not opinionated.
Fairly off-topic, but I've been having the hardest time finding a Wireguard configuration guide that lets me connect two peers (my phone and an SBC at my house behind my router) to a VPS peer (with a public IP) in a way that routes all the traffic from my phone through the SBC (via WG) and out to the internet via my home fiber connection. All the blog posts and tutorials I've seen have traffic going out through the VPS peer, with little explanation of how all the firewall and iptables commands might change if I wanted a different configuration. Has anyone seen a configuration like that, or know which networking concepts I should keep searching for to go in the right direction?
It is a layer 3 vpn that supports v4 and v6 payloads. It does not support any layer 2 connection like you would get from a tap interface.
You can certainly make a mesh of connections between different hosts by adding the remote peer's public key and ip address to each host's configuration. There is nothing in wireguard that makes that automatic though.
The point of WireGuard is to set up a VPN across the services you need. You could use it for point-to-point connections but it does much more than that.
What they want to do, cannot be done by Wireguard, because Wireguard does not have the concept of "VPN sessions / connections". What they probably need to do is to assign each customer a fixed private IP for use within their VPN, e.g. from 10.0.0.0/8.
When those are not enough any more, they need to segment their VPN, so they can re-use the private IP space in each segment.
w.r.t. to "NeuroRouting and TrackStop not possible", they could route their stuff through a TUN interface to do whatever they want to do in user space. With a performance cost.
Yes, wireguard is a point-to-point transport layer. VPNCloud includes a management layer about that. And for example deals with NATs, network management etc.
In general it seems convenient to configure; but in terms of operation how does it really differ from connecting your services as clients to a VPN LAN? With WireGuard for the tunnels themselves, you can even have as many routers/"relays" as you want, with virtually no overhead.
You can run dynamic routing protocols such as OSPF or iBGP over Wireguard. It's not built in, but that's a feature, not a bug—I vastly prefer software that does one thing and does it well.
I have a full mesh of Wireguard tunnels configured between home/office/datacenters/laptop, and run bird[0] on the VPN endpoints to direct traffic between them.
The only downside with WireGuard for me is that it only works over UDP. I am in a situation where I only have two or three TCP ports available for a VPN, so I won't be moving off OpenVPN anytime soon.
I was following WG development for a while now and I think it's a great project, but sadly not for my particular use case.
Can you point me to some docs on how to accomplish this? I'm currently using Slack Nebula to achieve similar goals but every time I looked up WireGuard tutorials, it was to tunnel traffic through a VPS, which I didn't want to do.
'Buying a VPN subscription' is just one use-case. Usually, those VPN services are intended to be used to circumvent geo restrictions.
WireGuard is not only about that. Sure you could do it. But it is applicable for any use-case where you have two or more machines that need to talk over a secure tunnel, over an otherwise not proven to be secure network(which is usually, but not always, the Internet). This ranges from connecting to a machine you have at home, to exchanging data between two office branches, and so on.
By using a WireGuard VPN you could actually be connected to multiple endpoints at a time, if you are able to set the same tunnel IP for all endpoints.
That would enable you to have that one connection open routing to different servers (Mullvad / Homelab / Offsite Lab / Work / etc ...) hence also using your own DNS resolver with a commercial VPN.
A VPN is one use of a Wireguard tunnel. Wireguard establishes a stateless encrypted connection between two peers, and exposes it to the user as a network interface. Endpoints can roam as with mosh
There's no problem having several wireguard connections enabled at the same time. Routes are selected per metrics/distance.
E.g:
A private virtual network between you and remote hosts won't be interrupted by the presence of a VPN service. The entry connection to the private network would be routed through the VPN service, though.
WireGuard is great, but I think it's really undersold when it's described as being just a vpn. It's really an encrypted tunnel that is configured like a network adapter in the Linux network stack.
This lets you configure it with stuff like systemd-networkd and unit files, or easily spin up a tunnel with a few `ip` commands, and setup some simple nftables rules to do all sorts of stuff.
I do use it as a vpn as well, but it's so much easier to setup than, say, OpenVPN, where you need to create tun/br interfaces and then tie them together with a service, etc. That said, OpenVPN and other actual VPN software does more than just a tunnel (like pushing routes, config settings, etc), so WireGuard cannot replace everything by itself.
The documentation is rather sparse, but there isn't much to it either. The manpages have what you need to know and the rest is just general Linux network stack knowledge.
You can split the tunnel based on IP routing, but I think that's as good as it gets. So if you want to Wireguard specific traffic to your peer then you're fine. For instance, we have our internal cloud network linked to our offices via wireguard, but traffic to anything that is not that network goes to the public Internet via our fiber.
But if we wanted to send HTTP requests always through the WG, that is not possible to configure because WG acts as an L3 VPN and Layer 3 has no conception of anything but the network. You couldn't say "Send HTTP requests through my normal fiber, but DNS requests through my VPS peer".
reply