perara / wg-manager

A easy to use WireGuard dashboard and management tool
MIT License
594 stars 74 forks source link

Built-in traffic obfuscation #19

Open TR-SLimey opened 4 years ago

TR-SLimey commented 4 years ago

While this might be considered out of the scope of this project, it might be cool to include an option to obfuscate traffic using udptunnel or udp2raw as mentioned in https://www.wireguard.com/known-limitations/ (TCP Mode).

perara commented 4 years ago

This is definitely something that could be done. I would have to look deeper into the matter as I've not used these myself. Option 2 would be someone adding this with a PR

TR-SLimey commented 4 years ago

I believe this option would also require a custom client for testing and use which would be a pain, though I could look into creating one eventually since wireguard is supposed to be easy to use in many environments and languages. Not much help I can give implementing this in wg-manager though.

As for the client, if I get around to creating one, I can currently test on (and create it for) Android and Ubuntu (plus Windows and Other Unixes in VMs). Do you have any of those platforms?

perara commented 4 years ago

Perhaps the solution here would be to have two docker containers, one for the obfuscating and one for wg-dashboard. It should be easy to map routing by "exploiting" environment variables

TR-SLimey commented 4 years ago

I don't have too much experience with docker so I can't really comment, though it seems like a pretty good idea. Wouldn't this make it much harder to install on bare metal though? And also to control the obfuscation from the panel?

perara commented 4 years ago

Just have to ask. Why would you ever want this? Isn't the traffic encrypted, to begin with?

TR-SLimey commented 4 years ago

Of course. That's part of the reason to using a VPN. However, some firewalls are not too keen on allowing people to use VPNs so they block any VPN traffic using DPI. Some also block UDP altogether or throttle and limit it with QOS. Traffic obfuscation can make the VPN connection work on more networks (though it will make it a bit slower hence it shouldn't be on by default probably) and possibly even make WireGuard usable in places like China. If this feature gets implemented, I think this will be the first project to actually obfuscate WireGuard data, which might make it all the more interesting to users.

HappyShr00m commented 4 years ago

This would be a reaaally great feature. Where i live, if you use the vpn on a 4G network, it will be throttled hard and basically be unusable. Only obfuscation works. So far I couldn’t make wireguard with obfuscation. So Im extremely interested if you can do it and hopefully it is still on your radar.

Also, do you think it would be possible for a client on iOS or just android phones ?

perara commented 4 years ago

Aight, I'll look into the obfuscation part. However, it is out of scope to create a client for iOS for this project :)

HappyShr00m commented 4 years ago

Aight, I'll look into the obfuscation part. However, it is out of scope to create a client for iOS for this project :)

Awesome man. You'll be the first to implement this in a usable way. and of course I understand regarding the iOS client. I'll keep an eye and again thanks for your effort.

perara commented 4 years ago

Aight, So from what i gather, shadowsocks seems to be good for this pupose, and as mentioned, a additional client is required on client side. The plan is to incorporate client and server mode anyways for site-2site configurations so to have a env flag for starting shadowsocks on top of wg should be fine. @HappyShr00m , @TR-SLimey , would shadowsocks be sufficient, or do you have better suggestions?

TR-SLimey commented 4 years ago

@perara shadowsocks seems to use SOCKS5 which is good, but easily blocked with DPI. So that still leaves one problem unsolved.

Alternatively, udp2raw could work but requires root access on the clients which is a big downside.

Another alternative is udptunnel (another link) which claims to be able to convert UDP traffic into TCP, bi-directionally and does not seem to require root access, though it doesn't obfuscate traffic.

Then there's the udp_obfs project which specifically obfuscates UDP traffic but doesn't convert it to TCP which then leaves the UDP blocking problem unsolved but should stop DPI.

Lastly, there's the good ol' obfsproxy by TOR which is probably the best solution if it plays nicely with WireGuard.

perara commented 4 years ago

@TR-SLimey Sorry for taking in this slow. Just to verify, Since you mention obfsproxy I then assume that sending the traffic through the tor network would accomplish this?

That should at least be a non-issue, but of course, it would be a severe performance hit.

Edit Ive read abit on https://github.com/wangyu-/udp2raw-tunnel and this looks to be pretty good, but as you mention need root. Perhaps there could be two options. Udp2raw and tor as obfuscation backends

TR-SLimey commented 4 years ago

@perara obfsproxy doesn't necessarily require using the TOR network. It's a separate software developed for use mainly with TOR I believe. It doesn't require root and can imitate a number of other protocols iirc, and also works on Android because it's built into the TOR browser app, again iirc. That's why I think it's the best option if indeed it does work here.

( Another (more detailed) obfsproxy page here )

As for udp2raw-tunnel, yeah, it sounds great, but there's always that one issue. Giving it as an option would certainly be good but I think that's too much of a flaw to use it as the main obfuscation method, especially if there's any intention of using this on iOS or Android.

perara commented 4 years ago

@TR-SLimey I've done some initial work for implementing obfs4 tor bridge. This works OK. From my understanding, a tor bridge is essentially a "private" entry point to the tor network, where the purpose is to circumvent block lists of known entry points. So this solves the "obfuscation part"

Just to verify, I'm imagining something like this: Application -> wireguard -> obfs client -> tor network (or something else) -> obfs decode -> wireguard I think this will work for Linux, but I am not finding any good solution on how to route the WG traffic into a secondary VPN on android. Specifically, I've looked at Orbot, which seems to work fine with the obfs4 bridge.

Also, it would be awesome if it is possible to specifically define the exit node to use in the tor network so that the obfuscation goes only does 1-hop and ends at the server, where the wireguard server is also located.

This would have been quite trivial to do if WG supported pluggable transports. But this is not the case. Another solution I've seen mentioned is shadowsocks with v2Ray, but I've yet to find any documentation if this method still works against GFW

TR-SLimey commented 4 years ago

@perara I think there's still a little bit of confusion. Obfsproxy is completely separate from TOR and doesn't actually require sending anything through the TOR network. The route you provided is more accurate like so:

[Application -> WireGuard -> Obfs4Proxy Client Side -> Obfs4Proxy Server Side -> WireGuard -> ...]

Here's a blog post about using OpenVPN with Obfs4Proxy which seems quite detailed and useful: https://www.comparitech.com/blog/vpn-privacy/hide-openvpn-traffic-obfsproxy-on-windows-and-linux-ec2/ . It seems to also talk about use on Windows so desktop cross-platform compatibility looks okay.

As for use on Android, I've started to look into modifying the WireGuard app (and making my own derivative) to allow the use of Obfs4Proxy. The sources for the original app are here: https://git.zx2c4.com/wireguard-android/tree/ . I intend to basically glue those with the sources of Orbot which are here: https://gitweb.torproject.org/orbot.git/tree/ . Unfortunately I have very limited time to work on this so feel free to experiment yourself too.

As for shadowsocks and v2Ray, I have never heard of it so can't help much here.

perara commented 4 years ago

@TR-SLimey Thanks for the clarification. The provided guide looks good and the proposed arch is more like what I was hoping for (this opens up for any type of obfs in that layer)

I think the misunderstanding comes from that obfs4proxy (https://hamy.io/post/000d/how-to-hide-obfuscate-any-traffic-using-obfs4/#gsc.tab=0) is made in context of tor (https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/README.md) whereas the old obfsproxy (3 and below) has unmanaged mode, which is not the case for obfs4proxy [ERROR]: obfs4proxy – must be run as a managed transport

I'll do further investigation

elpocoburrito commented 9 months ago

I'm highly interested in this project/implementation of wg obfuscsrion. Is this still being worked on or was it abandoned/put on hold? I notice the last comment/commit was 1 year ago.