UDP (without Tor) doesn't work?

[mvevitsis]

I am not using tor, however, the DNS log shows that outgoing UDP connections are still being blocked.

I am using a socks5 proxy for outgoing traffic. I am also using the firewall, however the apps in question have been allowed. Other traffic works ok.

Is this the intended behavior? Do you also need to give an app LAN access to allow UDP?

[Gedsh]

I am using a socks5 proxy for outgoing traffic.

The socks5 proxy in InviZible does not support UDP. UDP will work if you use a direct connection.

[mvevitsis]

I am using a socks5 proxy for outgoing traffic.

The socks5 proxy in InviZible does not support UDP. UDP will work if you use a direct connection.

Should I enable the force TCP toggle even if I am not using tor?

Also, is it possible to add UDP support? It seems like technically it is possible as some similar apps seem to have implemented it (e.g. rethink).

[Gedsh]

Should I enable the force TCP toggle even if I am not using tor?

The Force TCP option forces DNSCrypt to use TCP instead of UDP for the native DNSCrypt protocol. And that's all it does. It must be enabled if you are using DNSCrypt over Tor. In other cases, it is optional. But I prefer to keep it enabled, as it improves reliability when using DNSCrypt anonymising relays.

is it possible to add UDP support?

It is technically possible, but in practice it is very complicated. InviZible uses NetGuard core code for VPN mode. NetGuard doesn't support UDP for proxy, and I can't add it myself since the NetGuard core is written in Clang. I only know this programming language to fix some minor things, but not to add such major ones. My programming languages are Java/Kotlin and Go. Also, I can't use the source code of other apps like RethinkDNS, as the VPN mode is completely based on NetGuard core code.

Since InviZible doesn't support UDP for proxy only, I don't plan on fixing this issue anytime soon, as not too many people need this feature. If the Tor developers implement UDP support, I will find a way to fix it.

[mvevitsis]

Should I enable the force TCP toggle even if I am not using tor?

The Force TCP option forces DNSCrypt to use TCP instead of UDP for the native DNSCrypt protocol. And that's all it does. It must be enabled if you are using DNSCrypt over Tor. In other cases, it is optional. But I prefer to keep it enabled, as it improves reliability when using DNSCrypt anonymising relays.

is it possible to add UDP support?

It is technically possible, but in practice it is very complicated. InviZible uses NetGuard core code for VPN mode. NetGuard doesn't support UDP for proxy, and I can't add it myself since the NetGuard core is written in Clang. I only know this programming language to fix some minor things, but not to add such major ones. My programming languages are Java/Kotlin and Go. Also, I can't use the source code of other apps like RethinkDNS, as the VPN mode is completely based on NetGuard core code.

Since InviZible doesn't support UDP for proxy only, I don't plan on fixing this issue anytime soon, as not too many people need this feature. If the Tor developers implement UDP support, I will find a way to fix it.

I guess another possible solution would be to add the option for a wireguard upstream (to use instead of the socks5 proxy), then the 'proxy to work profile with vpn installed' workaround to use a 'real' VPN alongside invizible's local VPN would not be necessary.

Wireguard itself is written in go, so maybe it's easier to implement as well. It is available in rethink; might be possible to use that as a reference.

(I don't want to just use rethink because it does not handle lan traffic correctly for apps like kde connect and localsend, and especially now that I got the local doh feature of dnscrypt working; these are big advantages of your app. I could never get ech to work with a local VPN type app before).

[Gedsh]

a wireguard upstream

#254

[mvevitsis]

a wireguard upstream

#254

The procedure referenced here:
https://github.com/Gedsh/InviZible/wiki/Using-InviZible-alongside-with-VPN

would also not allow udp traffic.

So I think it is worth integrating wireguard, if enabling UDP for the socks 5 proxy is too difficult.

The reason: some android apps do not behave properly without UDP (e.g. Facebook messenger).

[Gedsh]

some android apps do not behave properly without UDP

The problem occurs only when using the socks5 proxy. In other cases, you can simply exclude UDP from Tor or exclude the app from Tor completely.

I think it is worth integrating wireguard

To use all the features of InviZible, such as firewall or bypassing LAN addresses, the NetGuard core code is still required, which does not support UDP for proxy. Implementing wireguard without all these features makes no sense, since you can use any other app with wireguard for this purpose.

The only real solution is to add UDP support to the core NetGuard code. I would most likely need a professional Clang developer to do this, which is quite expensive for the current level of donations to the project.

[ignoramous]

don't want to just use rethink because it does not handle lan traffic correctly for apps like kde connect and localsend, and especially now that I got the local doh feature of dnscrypt working; these are big advantages of your app

If one desires the same behaviour as InviZible with Rethink, one can enable Do not route Private IPs in Configure -> Network. @GDESH can correct me, but InviZible, by default, lets private IPs and multicast/broadcast traffic bypass it's VPN tunnel (which is why apps like localsend work out-of-the-box).

Since InviZible doesn't support UDP for proxy only, I don't plan on fixing this issue anytime soon, as not too many people need this feature. If the Tor developers implement UDP support, I will find a way to fix it.

Someone did submit UDP support as PR, but Marcel avoided merging it as he didn't want to add anymore new features: M66B/NetGuard#523

My programming languages are Java/Kotlin and Go. Also, I can't use the source code of other apps like RethinkDNS,

Happy to help in case you want to use firestack instead (:

Also, Mercury Li's building a pure Kotlin-only (tun2socks) network engine, which is another option. lihenggui/blocker#406

[mvevitsis]

If one desires the same behaviour as InviZible with Rethink, one can enable Do not route Private IPs in Configure -> Network. @GDESH can correct me, but InviZible, by default, lets private IPs and multicast/broadcast traffic bypass it's VPN tunnel (which is why apps like localsend work out-of-the-box

That would not work with "block connections without VPN enabled" when using rethink.

It does work with invizible, however.

[ignoramous]

It does work with invizible, however

My understanding is, this will stop working (even with InviZible) once Android fixes this routing anomaly (which, to me, looks like a leak) in their network stack.

[mvevitsis]

It does work with invizible, however

My understanding is, this will stop working (even with InviZible) once Android fixes this routing anomaly (which, to me, looks like a leak) in their network stack.

The bug report on Google right now is regarding incoming connections, which could be a leak.

The outgoing connections already work as intended. If it's not routed through the VPN it is blocked. Most VPNs ignore private IPs, but invizible doesn't because it needs to own these connections to apply its firewall rules (if the user enables the firewall).

Personally, I wish Google would just give us a toggle to fix this problem (allow private IPs in lockdown, on or off). Then any VPN app should work.

[ignoramous]

Most VPNs ignore private IPs, but invizible doesn't because it needs to own these connections to apply its firewall rules

From my reading of the code, InviZible does the exact opposite of what you describe. I may be wrong; Gedsh can clarify, if so.

The outgoing connections already work as intended.

Unsure about KDE Connect, but a recent bug report mentioned outgoing connections for localsend works with Rethink. It is incoming that doesn't. That said, we don't yet test LAN / P2P apps, so you are absolutely right that Rethink is pretty poor at P2P / LAN.

[Gedsh]

InviZible, by default, lets private IPs and multicast/broadcast traffic bypass it's VPN tunnel

You are right, but not entirely. The Bypass LAN option is enabled by default. But all traffic still passes through the local VPN and then is routed with the magic of the NetGuard code to the desired destination, like Tor or a direct connection.

It does work with invizible, however.

Because technically all traffic is still running through the VPN.

this will stop working (even with InviZible) once Android fixes this routing anomaly

This will continue to work. Android indeed has a VPN tunnel leak, but it's only related to the captive portal. InviZible uses legitimate technology, so the feature will work stable.

Someone did submit UDP support as PR, but Marcel avoided merging it as he didn't want to add anymore new features: M66B/NetGuard#523

I saw it a long time ago and had high expectations for that code. But unfortunately it doesn't work, and I haven't been able to fix it as it seems to have fundamental problems.

Happy to help in case you want to use firestack instead (:
Also, Mercury Li's building a pure Kotlin-only (tun2socks) network engine, which is another option. lihenggui/blocker#406

Thanks for the suggestion! But InviZible is highly tied to the NetGuard core code. It is extremely fast, flexible and stable. In addition, I know it quite well, as I have had to modify it many times to meet my needs. I don't think any other code has comparable capabilities.

[ignoramous]

Thanks for your answers.

The Bypass LAN option is enabled by default. But all traffic still passes through the local VPN

The VpnBuilder code (here) excludes broadcast and multicast routes explicitly. Do the packets destined for those routes end up in InviZible's tunnel despite that? Or, do I misunderstand?

For Rethink, from what I've observed, when the multicast/broadcast routes are excluded (like so), packets don't flow through its tunnel.

I'd want to make broadcast/multicast work with Rethink for P2P/LAN apps, and I've been on the look out for examples like InviZible that might help me (@mvevitsis encouraged me to look at InviZible for inspiration: celzero/rethink-app#1618), but I guess my lack of knowledge about networking ends up making it difficult.

[Gedsh]

The VpnBuilder code (here) excludes broadcast and multicast routes explicitly.

You're right. But this is not the only place.

InviZible/tordnscrypt/src/main/java/pan/alexander/tordnscrypt/vpn/service/ServiceVPN.java

Line 468 in 958c111

if (isIpInLanRange(destAddress)) {

For Rethink, from what I've observed, when the multicast/broadcast routes are excluded (like so), packets don't flow through its tunnel.

I've noticed that phone manufacturers like to play with routing tables, and sometimes it doesn't work as intended. Therefore, InviZible excludes multicast and broadcast addresses both from the VPN tunnel and for packets that are already inside the VPN tunnel. LAN addresses are excluded only for packets that are already inside the VPN tunnel. I mean that these addresses are excluded from routing to Tor or proxy.

but I guess my lack of knowledge about networking ends up making it difficult.

I also have no academic knowledge of networking. So I prefer an experimental and practical approach. I spent some time with apps like Syncthing to make it work with InviZible. I was intercepting packets, analysing what was being blocked or routed wrong, and fixing it. So it was a continuous process. Unfortunately, I don't have a definitive answer as to what exactly did the trick. I think it's a complex of all the provided solutions.

[DI555]

@Gedsh ,
Hello, many good wishes!!!
As we all want to make IZ better,..

Is the source code of pcapdroid (it’s with firewall now) suits to be good or better for IZ, instead of NG ???
(it might be no any Clang there !!!)
(github.com/emanuele-f/PCAPdroid)

[Gedsh]

@DI555 Hello, Thanks!

I have no any plans to change the app core as NG is perfect, except that it doesn't support UDP for proxy.

it might be no any Clang there !!!

Of course it's there :))) https://github.com/emanuele-f/PCAPdroid/tree/master/app/src/main/jni

[DI555]

yep, NG is pretty fast :// ..
but, could it be possible to add manually changes for udp socks5 to IZ using that commit ?

[Gedsh]

Please read the discussion above. It doesn't work.

[DI555]

oh, yes, pardon, of course,
..may be the dev of NG fix udp working some day, but he has always a bad mood((