supports SOCKS5 udp relay

[shenm233]

No description provided.

[M66B]

Thanks for the pull request, it will take me some time to review this.

At this moment I have one question: is UDP traffic forwarded through the SOCKS5 proxy being filtered by NetGuard? At first glance it is not, which would defeat the purpose of NetGuard.

[shenm233]

Yes, it is implemented just as same as TCP traffic forwarded through the proxy.

[M66B]

I am considering to merge this. Do you agree that I get the copyright of the source code and that the source code will be licensed as GPLv3 as outlined here: https://github.com/M66B/NetGuard/#contributing ?

[shenm233]

Yes, I am agreed.

[M66B]

Thanks. I am not sure if I want to merge this. Merging also means that I need to maintain and support this and not many people will be using this feature. Op do 22 aug. 2019 om 02:19 schreef shenm233 <notifications@github.com>:

…

Yes, I am agreed.

[xDragonZ]

Currently UDP traffic is being ignored and dropped by netguard?

[M66B]

@xDragonZ no it is not. UDP traffic can be blocked, just like TCP traffic.

[tlaurion]

@M66B
UDP traffic cannot be proxied through orbot. Merging this would be a first step into making UDP traffic not go straight to the internet for people requiring added anonymity.

I would definitely play with that feature and ROM projects like e.foundation or Replicant would also benefit of a feature like this to educate people with application network behaviors ad hoc. e.foundation could integrate your app with safe defaults and proxy internet TCP traffic through orbot by default, while UDP traffic is still questionable.

I would love to see this feature merged.

[licaon-kter]

@tlaurion Netguard already can block UDP, this PR is not about that.

[tlaurion]

@licaon-kter : No. I'm not talking about blocking UDP, but proxying UDP traffic just like TCP traffic can be proxied so that all TCP traffic goes through orbot (tor), as an example.

By forcing NetGuard as an always on VPN on both working and main profiles, this guarantee that the TCP traffic doesn't leak to connected network in clear. The same can be done right now for DNS traffic, let them be TCP/UDP , through port forwarding, see screenshot.

What to do with this UDP traffic and where/when to proxy it is another question, but this PR would be a good first step in that direction, let it be for I2P or other anonymization networks permitting proxying.

Attached are DNS leak tests. No, I'm not in Netherlands.

Attached is port forwarding config for this DNS redirection to work, even for UDP, where ports are known, which is not the case, for example under Signal calls.

Attached is TCP proxy config, forcing all TCP traffic through orbot. Hope use case is clearer while not completely figured out.

[licaon-kter]

All this setup and then you use Signal and Frost for Facebook...that's funny. ;)

[tlaurion]

All this setup and then you use Signal and Frost for Facebook...that's funny. ;)

Unfortunately, yes. Need message notification for personal/professional interactions with the rest of the world... Didn't choose to live in a cave, yet.

You know, confidentiality, conviviality and availability triangle. Gotta promote something enough convivial to reach everyone. And something enough available and confidential enough (ephemeral messages: not trusting devices) to have a reasonably confidential channel to exchange secrets without asking everybody to be geeks...

I haven't found anything perfect, yet. This is out of scope, but i'm always ready for better suggestions. I still think ephemeral messages on something available and convivial as Signal to be the best compromise. For Facebook, I can't justify... I still want to have contacts with my family and friends :P

Anyway! I hope this clarifies the need for some threat models.

Things are moving fast and forward for the [secure smartphone realm](https://zn.amorgan.xyz/1DMb3CV66qZPwJqkgm4z12nu8BrAwDoD4g/?Post:27:Experiments+on+the+Note+II+(N7100+[codename+t03g],+still+maintained+LineageOS+14.1+for+MicroG+by+e.foundation!!!).

TLDR: It would be nice that the most interesting tool, pedagogically speaking (Yes, NetGuard here), already supports what will need to be enforced for secured communications.

That's where I stand :)

[shenm233]

Without UDP proxies, it would expose original IP address to third party, which breaks anonymity. And some network censorship restricted regions, they will block all traffic to some IPs, however TCP proxying is no enough, with UDP proxying makes website or other services more accessible.

[licaon-kter]

What website do you use over UDP?

[shenm233]

However WebRTC can use UDP for transport, I don't know which websites use this, also some services or apps (for example, video chatting) may use UDP traffic.
You can learn more about WebRTC leakage.

[seonwoolee]

Any updates?

@shenm233, would it be possible for you to upload an apk of your fork as a release under your version of the repo? I am quite interested in proxying UDP traffic.
I tried compiling the app from source but I have never compiled an Android app before and ran into errors that I didn't know how to handle.

[sudomain]

Could this be merged if the feature was labeled 'experimental' ? Maybe with an addition to the FAQ about how experimental features won't always work?

[SsomsakTH]

Good

[jgoerzen]

I would just like to add that UDP is going to become much, much more prominent in the near future, as HTTP/3 uses QUIC which is UDP-based. It's not on by default in any browser yet, but it is present in all major browsers. Mobile most definitely stands to benefit, so this is going to be key for Netguard.

[rullskidan]

Why has this not been merged yet? I really need this feature.

[seonwoolee]

Bump. I have been looking forward to this feature.