The answer to which I'm trying to figure out.
Thus far, it feels like the answer is 'yes'. I'm guessing here, but ... I expect a fair bit of the reason for torrent / udp success is udp nat hole punching. With the dearth of sock5 udp capable relays, forwarding seems appropriate.
However ... forwarding was turned off, presumably for good reason. [Yes, I caught your note - essentially, forwarding is turned off by default in Linux, ws didn't need it, so the default was left unchanged.] But who knows what else will leak through, inadvertently, if forwarding enabled. Yet, can't prove a negative. e.g. Scrubbing proxies like privoxy exist for a reason. Comments that reduce the size of that negative haystack would be useful.
Currently using a debian ws default gatewayed to an openwrt box with vpn running as a non/Whonix sanity check. Thus far any discrepancies have turned out to be non-Whonix related. e.g. Proxy not working ... 2 days later happened to check non-Whonix to find it also not working. (What a supreme time waster that was.)
Thanks for the config snippet thought. Will bear that in mind. e.g. It's feeling like whonix_firewall calling a post-run script is going to be needed. Additional iptables rules are going to be required.
whonixcheck is not the least of my worries, by any means. One of the things I have noticed / been sensitive to ... whonix encapsulates a great deal of complexity for the non-technical end user. whonixcheck provides a very nice pass/fail as to something is wrong.
Thus the patch to note the undesired package to the user, even if it's a duplicate message in the mean time, so the user can actually do something about it.
And also, thus, BTW, ... updating the warning that ip forwarding is enabled to be in bold, red, would be useful.
Anywho, so part of the challenge here is to simplify things so that whonixcheck can do pass/fail/warn type things. Which is to say, as I work through this ... I have to keep in mind to K.I.S.S. so the ultimate end user has easy implementation and pass/fail whonixcheck detection.
So much complexity in all this. I've read so much, and so much of it is a blur. So much only half understood, and left behind as a result. Then, days later, if I happen to come across it again, more of it gels.
One thing I can say is ... this all shouldn't be this hard. My industry ('computing') is self-inflicting its own pain, disserving its customers. <sigh>
For example (a): several torrent clients will bind to a specific interface. Such a virtual interface, with its own IP, would provide an ip tables mechanism (by source address) to identify / segregate / separately route designated traffic.
- yet I have been unable to find a simple description to create such an interface. [Return to ... material read several days prior, skipped at the time, and now can't find again.] Various things like 'ip tuntap add dev veth0 mode tap' | 'ip link set name veth0 dev dummy 0' | 'tunctl' end up with a 2nd eth0 matching gw and routing falls apart.
- never mind such would be technical steps for a non-technical ws user to execute.
For example (b): Then I find that such interface bound clients don't always use that interface. e.g. udp bypassing socks5 settings. Never mind if the interface isn't up (triggering defaults to all interfaces), or the app has no interface or proxy configuration settings.
IIUC, in essence, the VPN, or OpenVPN, bundles within itself the 'proxying' capabilities. It has to - by very definition and point of a VPN. 'proxying' here, is essentially, forwarding on your behalf (aka NAT) - the very definition of proxying. Forwarding == relay ... and we're back to enabling ip forwarding. <sigh>
Thus, if such traffic could be corralled, all that should really be needed is a relay. This, then, is the basic problem: how to corral / identify appropriate traffic. e.g. As currently set, whonix permits the traffic it can, and roadblocks all other traffic. This is a wonderful thing. Problem is, to specifically identify the now to be permitted traffic, only, so that the unexpected traffic still gets roadblocked by native whonix.
My expected solution, thus far, is to also specify a socks5 proxy in the client app - thus providing a mechanism to identify / corral / route excepted traffic. [Return to above ... turns out even setting an interface / socks / proxy, an app doesn't always use it. <sigh>]
There are OpenVPN config settings for proxies / socks to use, but these are under hood fiddly bits I expect to be beyond the average target user of whonix. (It's hard enough to discern which vpn providers also provide socks5 services, to add discerning that such provide an openvpn config file with such settings embedded, is too much.)
Even as it stands now, additional openvpn config settings are necessary to yank default gateways (providing a vpn kill switch) [yes, I know in theory a kill switch is inherent to whonix]. It's not just 'apt-get install openvpn' 'download vpn provider's .conf file' and 'get on with your day'. If the vpn falls over, no gateway should be present until a user intervenes.
From what I can tell tun2socks doesn't udp.
Briefly looked at redsocks, but too goofy for words. i.e. This should all be simpler, having to change the group nixes all the base user understanding of groups and permissions ... there must be a better way.
It has been obvious that the correct way to do this all is to provide a tor equivalent alternate channel. Effecting that has just been a whole 'nuther story.
Seems like dante provided 'socksify application' is the next possibility to check out. (See: dearth of udp capable socks5 functionality.)
Which will have to be on ws, and leaves me puzzled as to how to ferret out such on gw to mangle appropriately. Seems like dante will need to run on both, and be transparent on one or the other. (Which should allow a dst=1080 redir 9050 alternate to the already in place whonix equivalent.)
Don't know of such a relay, but if found, perhaps ip forwarding could then be turned off.