Live data from Hacker News

A userspace WireGuard client that exposes itself as a proxy

github.com

51–60 of 91 posts

Re: A userspace WireGuard client that exposes itself as a proxy

#51

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…

> 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)

Re: A userspace WireGuard client that exposes itself as a proxy

#52
post #35

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…

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.

You can. You just need to use the right tools. See my uncle comment.

Re: A userspace WireGuard client that exposes itself as a proxy

#53
post #16

Why wouldn’t you just run ssh -D to the remote machine? The effect is the same and you don’t need wire guard or wire proxy.

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.

I want to point out a caveat to others: Proxifier != VPN

wireproxy's wg only forwards TCP and UDP. I am not sure how ICMP is handled. Other transports, though rarely used, won't be tunneled (and may leak, if not dropped).

Re: A userspace WireGuard client that exposes itself as a proxy

#56

Earlier quoted context omitted.

Do you have a source for this? Every page on Mullvad I've seen says you need to have the VPN active: https://mullvad.net/en/help/socks5-proxy/ > If you configure your browser, for example, to use the SOCKS5 proxy, it will direct all of your internet access via the proxy which is only accessible through Mullvad. So if you haven't turned on the app, your browser will prevent all internet access and therefore won't leak…

You just route 10.64.0.1/24 with wireguard, or 10.124.0.1/24 to access socks proxies on other locations. Then you have socks only mullvad.

if you are routing via wireguard, the VPN is active. Note, people are not talking about the mullvad app here (which is not required at all)

Re: A userspace WireGuard client that exposes itself as a proxy

#57
post #51

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…

> 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…

Are you sure what you described works? Last I tried it didn't work, and this is explicitly stated on wireguard.com:

> In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list.

> This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs.

Which is, I believe, also why zx2c4 called to revert the whole systemd-networkd feature.

I would really want it to work as it would simplify my network configuration by a bit. Please share a working example if you are able to make it work, thanks!

Last I tried that I used iproute 2 to manually setup interfaces, use wg setconf to load WireGuard configurations. So I don't think it's my tool to blame.

Re: A userspace WireGuard client that exposes itself as a proxy

#58

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…

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…

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.

Re: A userspace WireGuard client that exposes itself as a proxy

#59
post #57
post #51

Earlier quoted context omitted.

> 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…

Are you sure what you described works? Last I tried it didn't work, and this is explicitly stated on wireguard.com: > In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list. > This is what we call a Cryptokey Routing Table: the simple association of public keys and allowed IPs. Which…

> Are you sure what you described works? Last I tried it didn't work, and this is explicitly stated on wireguard.com:

If we're talking simply about decoupling routing from AllowedIPs, yes, using that right now and set it up several times. For redundant routers, see below.

> > In other words, when sending packets, the list of allowed IPs behaves as a sort of routing table

This does seem in conflict with my understanding... Depending on exactly what devil-details go into that "sort of", of course. Not deep enough into it to tell you, though.

> Which is, I believe, also why zx2c4 called to revert the whole systemd-networkd feature.

Rather the opposite AIUI; To allow for setting routes explicitly (which introducing the wg-quick behavior broke[0]).

What started making it click for me was this ArchWiki section[1]. The discussion under this GH issue may also provide some pointers[2]. Also [3]. IIRC I did get multiple outbound redundant routers with failover in the end. There may be WG-specific gremlins I glanced over but ascribed it to not fully grokking the Linux IP stack and issues with *tables in general at the time - the goal I had is hairy enough without Wireguard in the mix. Please report back here on your progress if you have the time :)

[0]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1003955

[1]: https://wiki.archlinux.org/title/WireGuard#systemd-networkd:...

[2]: https://github.com/systemd/systemd/issues/14176

[3]: https://www.eisfunke.com/article/docker-wireguard-systemd.ht...

-----

EDIT: Went back to take a look and I never did get proper HA routing sorted - ended up "solving" it with a script regularly checking reachability and bringing routes up/down accordingly. No need to bring the actual WG interfaces or IP assignments up/down for that, though.

Re: A userspace WireGuard client that exposes itself as a proxy

#60
post #16

Earlier quoted context omitted.

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.

I want to point out a caveat to others: Proxifier != VPN wireproxy's wg only forwards TCP and UDP. I am not sure how ICMP is handled. Other transports, though rarely used, won't be tunneled (and may leak, if not dropped).

To clarify, UDP is not currently supported, but I intend to support it in the future. Incoming ICMP should be completely dropped, and outgoing ICMP is not supported.
Post reply on HN