Gedsh
Consider localhost-based addresses (127.0.0.0/8, ::1) as either LAN or separate localhost firewall group in iptables firewall
The use case for treating localhost-based addresses specifically would be apps that communicate with one another over TCP/UDP sockets, in this particular example Termux talking with XServer-XSDL.
Currently, whenever at least DNSCrypt is enabled, apps have to discover the device's assigned addresses while being connected to an external network and use that information to connect with one another. Without Invizible running and without the kill switch enabled, the same apps communicate over localhost-based addressing without requiring an external network connection perfectly fine.
I've also noticed there is an explicit hard-coded exemption in the codebase for the localhost CIDR, so perhaps I'm missing something in this picture?
Are you using InviZible in Root mode? Do you have any specific issue when enabling the firewall in InviZible? Does disabling the firewall solve the problem?
Yes, using root mode (iptables), no issues when enabling the firewall, just apps unable to communicate with one another across 127.0.0.0/8 when any functionality is enabled or kill-switch is in effect and disabling all functionality along with the kill-switch fixes the issue.
disabling all functionality along with the kill-switch fixes the issue
This means that the problem is not in the mentioned code. It only applies when the firewall is enabled.
Do you have "Bypass LAN addresses" enabled in the Fast Settings?
The problem could also be with DNS. InviZible redirects all DNS traffic to DNSCrypt or Tor, since it is not possible to separate DNS traffic of different applications on android.
"Bypass LAN addresses" doesn't affect outcomes in any way.
I have to insist on disagreeing, as per original post, enabling any external firewall zone (for example WiFi, but not WiFi-LAN) on the listening app's end (in this case, XSDL) successfully allows Termux to connect. That would make sense, because at that point, both apps' UIDs are allowed to communicate virtually freely, even though the destination address is localhost/LAN-scoped.
However, if the listening app only has either no allowed zones or only LAN allowed (which omits localhost-based addressing, per code reference in original post), other apps are unable to connect to it's listening socket.
This becomes much more apparent once you look at iptables -t filter -S.