I don't get it, can someone explain? (we use a lot wireguard but I don't get it :( )
thanks
A userspace WireGuard client that exposes itself as a proxy
71–80 of 91 posts
Re: A userspace WireGuard client that exposes itself as a proxy
#72I don't get it, can someone explain? (we use a lot wireguard but I don't get it :( ) thanks
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.
Re: A userspace WireGuard client that exposes itself as a proxy
#73It is inconvenient to rewrite config from original wireguard config file.
I think i'm going to write a convert a wireguard config into a wireproxy config file. Hopefully that will make it easier for people to use.
Suggest to try with this - https://github.com/go-ini/ini
Wireguard config is ini format.
Re: A userspace WireGuard client that exposes itself as a proxy
#74What about UDP?
Not yet unfortunately. I'll add it in the future, but I'm preoccupied with homework right now.
i have yet to encounter a case where a udp-tunnel has a practical advantage over tcp; on the other hand, corporate/hotel/coffeeshop firewalls that block anything not tcp/443 are super commom.
Re: A userspace WireGuard client that exposes itself as a proxy
#75make it run on windows with a simple gui, subtly ask for donations and you're golden
Re: A userspace WireGuard client that exposes itself as a proxy
#76Earlier 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).
Most importantly missing: DNS, which usually is handled over UDP (changing slowly now with DNS-over-HTTPS and some TCP resolvers). Without handling DNS requests via your proxy, you're still leaking information about yourself to the resolver you're using.
Re: A userspace WireGuard client that exposes itself as a proxy
#77This is great, thank you!
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).
Re: A userspace WireGuard client that exposes itself as a proxy
#78Earlier 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…
I'm not sure how you conclude that AllowedIPs does no routing. > On a lower level, AllowedIPs is really just "allowed IPs", and does no routing. This is contrary to what the official documentation says https://www.wireguard.com/#cryptokey-routing > You can have multiple active peers with overlapping AllowedIPs. You can, but the most specific CIDR wins route selection, which is exactly what *routing* does.
Key words from that link emphasized:
> 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.
> the list of allowed IPs behaves as a sort of routing table
> This is what we call a Cryptokey Routing Table
You can just set your peers on separate wg interfaces. At least on Linux and BSD, 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.
It makes sense if you think of each wg interface as a NIC connected to an L3 switch, and each peer to a host connected to another port on the same switch. AllowedIPs would correspond to the table+ACL in the switch.
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.
While this understanding does come from a decent amount of experience, in case I'm wildly misrepresenting things, do set it straight.
Re: A userspace WireGuard client that exposes itself as a proxy
#79I don't get it, can someone explain? (we use a lot wireguard but I don't get it :( ) thanks
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.
uh, now I've got it, thank! :)
Re: A userspace WireGuard client that exposes itself as a proxy
#80Earlier quoted context omitted.
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.
Why not just split the peers up over separate wg interfaces?