Neat! How does yours work? The Go version of this is easy to write, because wireguard-go has helpers to drive Netstack, which is also written in Go. But yours is in Rust. (I could have dug in, but I'm being lazy).
This is good stuff. There should be, ideally, one really good tool for doing plugboard-y stunnel-y type stuff with user-mode WireGuard, where you don't need root to set up the tunnels, and this could be that.
I love wireguard but my one gripe with it is that its not a true data link layer. 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. With Ethernet, you can have multiple nodes in the same subnet acting as generic routers, it’s just a matter of sending IP packets to that host.
I hope someday wireguard addresses this issue and makes itself fully transparent as a data link layer.
> 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)
i just wish i could control the routing via routing tables instead, making dynamic routing decisions possible without specialized software that is able to manipulate it.
Wireguard is not a link layer (layer 2) tunnel; it is a network (layer 3) tunnel. It operates at the IP layer. You cannot use Wireguard with any non-IP layer3.
AllowedIPs can be disabled if you want; just set it to 0.0.0.0/0. AllowedIPs is needed because netfilter can't "see" which public key an inbound packet is coming from, so by the time a packet gets to netfilter it's too late to accept/reject based on which peer sent it to us.
This is cool! I was looking for something to integrate into an automated downloading setup. I had already setup a docker container that connected to wireguard and then the other containers would connect to the internet through that one, but doing it with socks is a lot easier and more of an out-of-the-box config. Decreasing complexity. Very nice!
A Docker solution[1] for the same thing using the official client. Performance can’t be compared with native kernel mode of course, but same technique can be used for other global proxy like OpenVPN.[2]
It would be really cool if you could use something like this in-process to open a "socket" that just happens to route over wireguard or another VPN.
E.g. you could easily have a bittorrent client use a certain VPN without routing all your traffic over it, or you could have a tab container in firefox use one connection, and another container another connection.
I used to run OpenVPN in a Docker container together with a SOCKS proxy for this exact use case (using a commercial VPN provider that doesn't offer SOCKS with different endpoints on a per-site/per-tab basis, without wanting to change my default route or non-browser traffic), but this is much more efficient (and safer).
I made it because my friends and I use wireguard to have a private network, and they don't feel comfortable running a ssh server on their machines. It can also be used with a vpn provider like Mullvad without setting up a new nic or requiring special privs.
One simple reason is that the serverside might not want to expose a shell to its clients, and instead just provide network connectivity; you can configure something like that with SSH, but it's a pain, and WireGuard is approximately as simple to set up as SSH, which is the primary reason it's so popular.
userspace means that the code runs in userspace so, it doesn't require admin privileges. So, it is great if you are not the root. Exposing socks5 is great, so that another userspace process can use it. So, let's say you would like to run a torrent client in a restrictive environment, you can setup this and then through sock5 interface, you might be able to bypass firewall around it.
momothereal|3 years ago
Though admittedly, mine doesn't have SOCKS support, and the code is not as lean as yours!
tptacek|3 years ago
russdill|3 years ago
Basically a kitchen sink for this sort of thing using lwIP for it's IP stack
tptacek|3 years ago
Scaevolus|3 years ago
This plays well with proxychains to make proxy-naive programs use SOCKS5 proxies.
RL_Quine|3 years ago
CyberRabbi|3 years ago
I hope someday wireguard addresses this issue and makes itself fully transparent as a data link layer.
3np|3 years ago
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)
mercora|3 years ago
octoberfranklin|3 years ago
AllowedIPs can be disabled if you want; just set it to 0.0.0.0/0. AllowedIPs is needed because netfilter can't "see" which public key an inbound packet is coming from, so by the time a packet gets to netfilter it's too late to accept/reject based on which peer sent it to us.
nikita2206|3 years ago
AdamJacobMuller|3 years ago
mistrial9|3 years ago
tormock|3 years ago
mosselman|3 years ago
AviationAtom|3 years ago
flatiron|3 years ago
metadat|3 years ago
(The below is meant to be tongue-in-cheek:)
>>> APT for your network... in a box! Market now ripe for someone to use this to deliver APT4UaaS.
robryk|3 years ago
octeep|3 years ago
rixtox|3 years ago
[1] https://hub.docker.com/r/curve25519xsalsa20poly1305/wireguar...
[2] https://hub.docker.com/r/curve25519xsalsa20poly1305/openvpn/
captainmuon|3 years ago
E.g. you could easily have a bittorrent client use a certain VPN without routing all your traffic over it, or you could have a tab container in firefox use one connection, and another container another connection.
Fritsdehacker|3 years ago
The websocket approach is a lot easier to configure, so I'm definitely going to look in to this.
lxgr|3 years ago
I used to run OpenVPN in a Docker container together with a SOCKS proxy for this exact use case (using a commercial VPN provider that doesn't offer SOCKS with different endpoints on a per-site/per-tab basis, without wanting to change my default route or non-browser traffic), but this is much more efficient (and safer).
TedDoesntTalk|3 years ago
octeep|3 years ago
tptacek|3 years ago
hotpotamus|3 years ago
unknown|3 years ago
[deleted]
hansel_der|3 years ago
unknown|3 years ago
[deleted]
oriettaxx|3 years ago
thanks
m00dy|3 years ago
NabiDev|3 years ago
octeep|3 years ago
nonrandomstring|3 years ago
amogoLP17|3 years ago
warner_of_doom|3 years ago
octeep|3 years ago
tptacek|3 years ago
lincw|3 years ago
tenebrisalietum|3 years ago
tptacek|3 years ago