whonix, torrents, and being a good tor citizen

Interesting, all. Thank you!

Seems tinyproxy is http/s only, no udp. But demonstrates a viable path of the concept.

Have also come across ‘stone’ (socat light?) http://manpages.ubuntu.com/manpages/dapper/man1/stone.1.html which is also in the repos. “p stone - TCP/IP packet repeater in the application layer” Came across it while googling upd proxy (or something), which is to say, apparently udp capable.

I’m getting the sense that something ‘invasive’ (additional package/sw) on the gw is unavoidable. Drats. (i.e. Wanting to preserve all the goodness that has gone into gw design.) It is also feeling perhaps not unreasonable to enable forwarding - the iptables rules currently present seem rather nicely tight. However … it was not enabled for a reason, and I’d not like to casually break it that way. whonixcheck will evidently whine, at the least. (Not inappropriately so, just that such will alarm most users.)

It has occurred to me to vpn on the ws itself, however all such traffic will be torified, and the point of the thread is to be a good tor citizen and not torrent over tor.

It’s also occurred to me that udp ain’t gonna work noway, nohow. Any gw mechanism will need to nat the traffic, and so probably won’t know where to send any incoming responses. i.e. Only full on forwarding is going to do it, and that’s turned off. Which takes me back to enabling forwarding, in a similarly rigorous manner to what is already present.

None of this seems optimal. Perplexing. From a majority of users perspective, it seems like it oughta be easier / there oughta be a way. That it isn’t isn’t a deficiency of whonix, merely, it is what it is.

ip forwarding is not enabled because for the current Whonix design it’s
not required at all. If you need it for your setup however is a
different question. If you find a way to make a non-Whonix
VPN-Workstation work behind a non-Whonix VPN-Gateway however that would
be good. However, not a blocker.

whonixcheck is the least of your worries. It can easily be configured to
skip certain tests. See its config file. Such a config snippet could be
easily deployed as part of an optional package.

JonDonym does not have a Trans- or DnsPort and yet you can use JondoNym
with transparent proxying. See:
HowTo use JonDo like a transparent proxy

Is there some software to interface with a VPN server through a socks or
http proxy port interface? I.e. a software opening a local socks proxy
port, accepting connections there and then creating a connection to the
VPN server. If the gateway would just provide other socks ports that
result in different network paths that would seem like a better design.

Not exactly tun2socks or redsocks. (But good to know something like this
exists.)

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.

[quote]JonDonym does not have a Trans- or DnsPort and yet you can use JondoNym
with transparent proxying. See:
https://anonymous-proxy-servers.net/en/help/transocks.html[/quote]

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.

[quote] Is there some software to interface with a VPN server through a socks or
http proxy port interface? I.e. a software opening a local socks proxy
port, accepting connections there and then creating a connection to the
VPN server. If the gateway would just provide other socks ports that
result in different network paths that would seem like a better design.[/quote]

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.

Well … nix danted (socksd) … Dante configuration -- Server chaining … “Forwarding of UDP is currently not supported by Dante.” Let alone … “Using authentication between two SOCKS servers is possible, but not currently supported.”

SS5?

Another option might be to not tamper with Whonix-Gateway at all. And
instead adding a VPN-Gateway. To the same internal network. Then the
Whonix-Workstation could be configured to by default use Whonix-Gateway
and selectively the VPN-Gateway for specific stuff.

Agreed, but this still makes the solution too complex.

Arguably, the whonix gw could then forward to the vpn gateway. Losing the vpn killswitch / whonix_firewall facility in the process. Not optimal. (Mind you, the openvpn config can effect the same via scripts / routing. I’ll post on that here at some point.)

However … still back to identifying and corralling the particular traffic to be so routed. And if that could be done, then the need for the vpn gateway is negated. (i.e. a ‘bypasstor’ tor equivalent.) e.g. equivalent to tcp 9050 redirect now, to, say, tcp/udp 1080, on both ws and gw I expect. One capturing, the other relaying.)

Equally arguable, would be a vpn client ws, also routing out the whonix gw as the whonix ws does. i.e. iptables identifiable source ip. I guess something like qemu would be equally topical.

It’s already irritating enough, and necessarily so, to have to run 2 vms. Expanding that to 3 or 4 seems excessive. ‘There oughta be a (simpler) law (way)!’

The beauty of whonix is K.I.S.S. and one stop shopping. The user shouldn’t have to remember to do activity a on vm a, and activity b on vm b. Especially as torrent as a file distribution facility seems likely to only grow.

[quote=“rAntOCauDgb, post:26, topic:1766”]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.
    [/quote]

Journalling notes …

stone didn’t work for me … but I now realize the proxy was brain dead, so I’ll have to revisit it.

So, as I may have said earlier … turns out clients such as ktorrent and qbittorrent are leaky. Specifying a proxy, socks5 or otherwise, does not necessarily mean all traffic goes out that way. Be it to trackers, or udp. Let alone if the proxy is down or the interface doesn’t exist at start time. e.g. Set to use tun0, but openvpn not started at time of app start.

So, it would seem that the desired solution would be something that encapsulates a program, forcing all net communications (perhaps with rules, e.g. dns) to go out as specified. e.g. (Dante’s) socksify, socks and socksd.

However, as mentioned, turns out Dante won’t use authentication when going up stream. [Looking through the whonix wiki, it notes a dearth of free / open source socks5 proxies / relays - it doesn’t seem too likely that a paid vpn provider isn’t going to required authentication.] This is part of what I meant about the sadness of the industry … (e.g. Dante’s) web pages that promise intuitively obvious functionality … then excepting the important bits in the fine print.

Alternately, instead of firing up a socksd on the ws, and possibly a socks5 relay on the gw to go out the openvpn tun0, one might consider per app invocation via dante’s ‘socksify {app}’ facility.

However, ‘socksify ktorrent’ crashes withing seconds. Googling reveals dante just falls over at exception and silently crashes. ‘socksify bittorrent’ did stay up and pass traffic - except the traffic all goes out directly, not via the specified socks5. Evidently dante/socksd is not part of any solution.

Next seems tun2socks, which seems to handle the magic mentioned above (‘Such a virtual interface, with its own IP …’, answering ‘I have been unable to find a simple description to create such an interface’) - however, as it doesn’t encapsulate a program, it creates a tun0 interface to bind programs to, it is arguable that this is no better than appropriate iptables rules on the gw - never mind as mentioned above that clients don’t necessarily pass ALL traffic over the configured proxy / socks5 / interface. (And I believe the same is true in ktorrent when a DSCP value is specified.) i.e. In the end, the whonix gw has to corral / guarantee no non-excepted traffic out non-tor. Partial solutions, ws or otherwise, merely add complexity without delivering certainty.

tun2socks does appear to promise udp forwarding - IF the provided badvpn-udpgw (udp gateway) service is run on the ssh server. This seems to imply the vpn provider running badvpn-udpgw … not likely.

OTOH, if someone knows … could badvpn-udpgw be run on gw, and something there simply relay such traffic to the running openvpn tun0 interface? If so, how? (I assume socat?)

https://www.giac.org/paper/gsec/2326/understanding-implementing-socks-server-guide-set-socks-environment/104018 is a really nice explanatory document!

Perhaps I’m thinking / going about this the wrong way.

There are 2 issues:

  1. Identifying / corralling net traffic.

  2. Proxying (udp / socks5) / anonymizing such traffic.

  3. Is inherently satisfied by the use of a trusted (openvpn) vpn provider.

  4. Docker? (Force all net traffic to a segregated ip that can then be identified and routed by iptables?)

e.g. Ramblings from Jessie: How to Route Traffic through a Tor Docker container

Docker seems over the top, in terms of heft. Not much different than running another entire vm (within the ws vm, even). [But the idea of lightweight containers seems attractive. One comment I saw noted LXC as entire OS’ and docker as single application’able. I noted the idea of a docker-whonix in the forum/wiki somewhere. Don’t know that I saw the thought of a docker app within whonix. torbrowser, icedove, torchat, with zero post-run footprint, seems like it would appeal.]

linux - How to use different network interfaces for different processes? - Super User seems topical, however I gave up on making it work. Multiple ‘ip link’ commands needed, bridge-utils, and script complexity; must be root to create the interfaces.

  • it’s initial attractiveness, however, is that it is scripting - not another package to install, and not binary/source hosted on ‘strange’ servers.

  • it is also limiting the containerization (and thus complexity and heft) to the network only, via network namespaces (ip netns). But brings bridging and other manual steps that I think would make the result unacceptable to whonix.

I have come across Binding applications to a specific IP | Daniel Lange's blog , however, this is compiling downloaded code, as opposed to a repository. e.g. http://www.ryde.net/code/bind.c.txt, Index of /lennart/projects/fixsrcip, http://www.semicomplete.com/projects/liboverride/, netjail - Browse /netjail/1.0.0 at SourceForge.net, or http://wari.mckay.com/~rm/bindhack.c.txt. In the first link, not even a page of code, in the last, perhaps two pages - most of it whitespace. Which is to say, easily code reviewed for unacceptable behaviour.

What is the general ‘whonix’ attitude toward such code? Assume GPL’ed/FOSS’ed, and so on. With no repository, no updates (but ‘this’ is a solved problem). Would ‘whonix’ be willing to take in a copy of such code and incorporate it?

  • not so much asking about this specific code as is even the very idea at all acceptable?

To review (this aspect) - the goal is to be able to identify, and so segregate, traffic. Be it for further control, processing, or manglement. This seems easiest if the app could be forced to run under a different ip address (containerized). Thus ip leaks (despite proxy settings) are contained, and could be forwarded to a local socks proxy (e.g. dante, if it worked), which forwards to a gw relay (e.g. stone).

  • not saying the additional processing is to be effected at the moment, or even optimal, merely that by isolating the traffic to its own ip, all such goodness is possible, when deemed desirable. [e.g. optimal - if dante worked, could easily be more efficient, for all I know, to forward the app to a rinet’ed port to dante running on the gw, as happens with tor now.]

In poking about containerization, I got to Flockport and encountered firejail. https://firejail.wordpress.com/ , GitHub - netblue30/firejail: Linux namespaces and seccomp-bpf sandbox Packages are downloadable at Download | Firejail

/etc/firejail contains parameter files, including:
Mathematica.profile
audacious.profile
bitlbee.profile
chromium-browser.profile
chromium.profile
clementine.profile
conkeror.profile
deadbeef.profile
deluge.profile
dnscrypt-proxy.profile
dropbox.profile
empathy.profile
evince.profile
fbreader.profile
filezilla.profile
firefox.profile
generic.profile
gnome-mplayer.profile
google-chrome-beta.profile
google-chrome-stable.profile
google-chrome-unstable.profile
google-chrome.profile
hexchat.profile
icecat.profile
icedove.profile
iceweasel.profile
kmail.profile
ktorrent.profile
login.users
mathematica.profile
midori.profile
mupen64plus.profile

opera-beta.profile
opera.profile
palemoon.profile
parole.profile
pidgin.profile
qbittorrent.profile
quassel.profile
rhythmbox.profile
rtorrent.profile
seamonkey-bin.profile
seamonkey.profile
server.profile
skype.profile
spotify.profile
steam.profile
telegram.profile
thunderbird.profile
totem.profile
transmission-gtk.profile
transmission-qt.profile
uget-gtk.profile
unbound.profile
vlc.profile
weechat-curses.profile
weechat.profile
wine.profile
xchat.profile

e.g. firejail qbittorrent

  • seemingly presenting the ability to containerize / isolate / segregate most any app to the extent deemed prudent. e.g. memory limiting.

Installation and use really was as K.I.S.S. as download, gdebi <package> ; firejail <your favourite app>

A default profile exists, and --noprofile is possible.

In this case a segregated network stack, and separate ip, is possible via:

  • firejail --net=eth0 --ip=10.152.152.111 qbittorrent
    – Note: I ran into problems of inaccessible files (in my non-default locations), until I commented out ‘noroot’ in the qbittorrent.profile. (Worst case in all of this is no worse than running the app natively. i.e. Without further 'whonix’ization.)

Sadly, ktorrent would not run - complaints about lack of access to dbus. (I see the problem has been noted - presumably this will be fixed at some uknown, unpredictable, future time.)

Curiously, there is a kmail profile, so dbus must not be getting its finger into each and every kde app.

So:

  • nailing down an app to run under a unique ip seems desirable. [iptables -A FORWARD -i eth1 -o tun0 -s 10.152.152.111 -j ACCEPT]
  • what is the whonix project’s attitude towards rarer source code? e.g. Just sucking in the file / original author not themselves doing so (thus no implied promise of keeping it updated).
  • is there value to containerization to the whonix project such that it would consider putting any time or energy into establishing the facility?
  • if firejail at all whonix topical?

We don’t have any compiled code for now. Nor any policy for this.

The closest to such a policy is this one:

Whonix firejail discussion:

Something super simple to answer “everything from the workstation is
always routed through Tor” becomes something less simple and more
insecure sounding “everything from the workstation is always routed
through Tor unless you install that package”.

/cc @HulaHoop since this involves compiled code, policy, firejail and
contributions.

Agree, but then, that’s why it’s optional.

However … whonix is already there. e.g. The enabling of VPN in whonix_firewall, so that bridge has already been crossed. In the sense of needing user intervention. (Given the mass of material already present about proxy/socks this way vs that way, before or after tor, the idea of ‘excepted tor’ traffic isn’t an onerous expansion.)

Getting to this tor-excepted traffic facility will be similar, and one, similarly user chosen, step beyond current VPN enablement - probably a whonix_firewall.d post-whonix_firewall-50user_run type call.

And some anondist equivalents. e.g. qbittorrent → qbittorrent.nontor → (sg vpnnet; qbittorrent.clearnet)

firejail testing fails for me at a ‘seamless user use’ (and works) level.

Have come across Index of /lennart/projects/fixsrcip which also fails, and http://freecode.com/projects/force_bind (see source tar.gz link top right) - which looks more promising. (netstat shows ip bound, but no net traffic at moment - I’ve probably played too much / need a reboot.)

It’s a single.c file, small, all of 113 lines long. Guts (whitespace cut):
[Accompanying LICENSE file notes GPL’ed.]

int bind(int sockfd, const struct sockaddr *addr, socklen_t addrlen)
{
int err;
struct sockaddr new;
struct sockaddr_in *sa4;
struct sockaddr_in6 *sa6;
void *p = NULL;
unsigned short *pport = NULL;
init();
if ((addr->sa_family != AF_INET) && (addr->sa_family != AF_INET6)) {
syslog(LOG_INFO, “force_bind: unsupported family=%u!\n”,
addr->sa_family);
return old_bind(sockfd, addr, addrlen);
}
memcpy(&new, addr, sizeof(struct sockaddr));
switch (new.sa_family) {
case AF_INET:
sa4 = (struct sockaddr_in *) &new;
p = &sa4->sin_addr;
pport = &sa4->sin_port;
break;
case AF_INET6:
sa6 = (struct sockaddr_in6 *) &new;
p = &sa6->sin6_addr.s6_addr;
pport = &sa6->sin6_port;
break;
}
if (force_address != NULL) {
err = inet_pton(new.sa_family, force_address, p);
if (err != 1) {
syslog(LOG_INFO, “force_bind: cannot convert [%s] (%d)!\n”,
force_address, err);
return old_bind(sockfd, addr, addrlen);
}
}
if (force_port != -1)
*pport = htons(force_port);
return old_bind(sockfd, &new, addrlen);
}

Not advocating it, yet, further testing to do, but you can see why I asked about the acceptability of such files. Small, easily code reviewed, and not really ‘big enough’ for a ‘maintainer’ once instantiated.

Probably not much different than a bash snippet, but it is code / needs compiling - and I have no familiarity with how projects manage such. Thus my question.

I am sorry to say, but I think the whole “selective traffic VPN-only” feature is too geeky and benefits too few users to invest time and effort into it.

As per recent blog post:
upcoming usability improvements that will hurt, TLS downloads, abolishing torrent downloads

Sorry to come up with this so late, but this thread partially contributed to me finally recognizing that while trying to suit everyone, I am loosing focus on the main stream work.

Thanks for this.

I’m curious if anyone has had success with these instructions; particularly the patching of whonix_firewall. I did not meet success. Wonder if it’s because it was for an older version of Whonix (and whonix_firewall)

Fair enough. But then, that’s why there are many hands.

Whether or not you ‘participate’, you can provide value, without sinking too much time into anything, by being a resource / guiding towards productive (produceable?) results.

e.g. The code bit above, but not specifically that code … guidance as to how to go about munging such into a whonix community acceptable resource, would be welcome.

Which is more about being a shepherd to the community, than spending time on a particular feature deemed at a community level as being of limited use.

However … this is also somewhat chicken and egg. I expect many have discarded whonix for lack of tor-excepted traffic / one-stop shopping. Having the ability to except traffic may well make whonix suitable for a larger audience. (No more use this for that, the other for the other, remember which you did what in. And why am I bothering with the vm / complexity of whonix, again?)

[I guess “why tor browser is not enough, whonix matters to you” could be more prevalent.]

In any case, I agree that such excepted traffic should be a bolt on, not a built in.

I suspect it’s not a version issue. There aren’t really any instructions, yet. Thus far it’s been merely topic explorative.

If you note specifically how you did not meet success, perhaps we can help.

I’ve put quite a bit of time in on this, and believe I have cobbled together a solution, but am still working on proving it out.

Stay tuned, details to come.

I don’t expect it will ever be part of mainstream whonix. And I have absolutely no idea yet as to how to go about formulating / depositing it as a whonix ‘addon’ that people can refer to and effect, if they wish.

Working notes … continuing …

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.
    [/quote]

For 2: Internally. whonix already has several proxies in play, be it browser, e-mail, or generally. By definition, and desire, all go through tor. It is the point of using whonix. Yet not all programs have settings to set proxies, http, socks4|5, or otherwise, so there is no easy or universal way by which to except particular traffic beside tor rather than through it.

Except, that is, for using a vpn, which is by definition a proxy, and routing all traffic through it. Yes, this is trusting that the vpn provider (truly) is anonymous, or sufficiently so. However, anonymity is -the- selling feature of many VPNs. OTOH … no way to prove a negative. It’s anonymous, until it isn’t, and by then it’s too late. Hopefully word will get out on providers that aren’t, and hopefully all concerned are paying attention when it does.

But then, I suppose the possibility is no worse than the possibility of a compromised tor node or honey trap.


So, for 2 - VPN. From a trusted provider.

Aside from using a VPN, the particulars of effecting non-tor traffic on whonix will be discussed another time. It will likely involve iptables rules, routing, and perhaps even policy based routing.

For 1, the challenge of identifying particular traffic so it may be constrained as desired, outside of tor, yet within the vpn (else one wouldn’t be using whonix at all) …

Solution, part a: Create and use an additional interface, and associated IP address, and thus provide breadcrumbs by which the whonix gateway can identify, permit, and route, particular traffic, and only that particular traffic, directly to the VPN.

One way to do this would be to create an additional virtualbox, internal network only, interface on both the whonix workstation, and gateway.

However, I instead propose creating a virtual interface on workstation only. Thus only users interested in this particular facility, and having manually installed it, are affected, and only when so running such designated programs. Impact is specific, leaving all other whonix safeguards in place, and in play.

On workstation:

First - # apt-get install bridge-utils

Manually -

brctl addbr br0
brctl addif br0 eth0
ip tuntap add dev tap0 mode tap
ifconfig tap0 192.168.2.1 up
brctl addif br0 tap0

Automatically:

  • mv /etc/network/interfaces.d/30_non-qubes-whonix /etc/network
  • this mv probably shouldn’t be needed / isn’t appropriate, but I haven’t gotten it to work by merely adding the tap0 and br0 bits to a separate file such as /etc/network/interfaces.d/50_user_add_whonix.
  • append to /etc/network/interfaces:

    auto lo
    iface lo inet loopback

iface eth0 inet manual

auto tap0
iface tap0 inet manual
pre-up ip tuntap add dev tap0 mode tap
pre-up ip addr add 192.168.2.1/24 dev tap0
up ip link set dev tap0 up

auto br0
iface br0 inet static
bridge_ports eth0 tap0
address 10.152.152.11
netmask 255.255.192.0
gateway 10.152.152.10

#ip tuntap add dev tap0 mode tap
#ifconfig tap0 192.168.1.1 up
#brctl addif br0 tap0

  • alternately, put the above in something like /etc/network/interfaces.d/50_user_add_whonix, but I haven’t tested that.

Leaving a distinct ip address (192.168.2.1) / interface (tap0) upon which to set a designated program to use, and by which the whonix gateway can discern such traffic.

e.g. Some torrent clients have a setting to designate the interface, or ip address, to use.

On gateway:

Pre-test:

ping 192.168.2.1 # - no response, expected.

Modify or create a file in /etc/whonix_firewall.d, such as 50_user_conf, creating or modifying a section to look like:

## Destinations you don not want routed through the VPN.
## 10.0.2.2/24: VirtualBox DHCP
#LOCAL_NET=“127.0.0.0/8 10.152.152.0/24 10.0.2.2/24”
#LOCAL_NET="
# 127.0.0.0-127.0.0.24
# 192.168.0.0-192.168.0.24
# 192.168.1.0-192.168.1.24
# 10.152.152.0-10.152.152.24
# 10.0.2.2-10.0.2.24
#"
LOCAL_NET="
127.0.0.0-127.0.0.24
192.168.2.0-192.168.2.24
10.152.152.0-10.152.152.24
10.0.2.2-10.0.2.24
"

Manually -

route add -net 192.168.2.0/24 dev eth1

Automatically - edit /etc/network/interfaces.d/30_non-qubes-whonix:

  • append a line to the ‘iface eth inet static’ section:

    <tab> up route add -net 192.168.2.0/24 gw 10.152.152.11

Alternately: Add ‘route add -net 192.168.2.0/24 gw 10.152.152.11’ to 50_user_conf above, rather than messing with files under /etc/network.

Run “whonix_firewall” to manually effect the change, without rebooting.

Test:
ping 10.152.152.11 # - should work, as expected.
ping 192.168.2.1 # - should work, now.


Next up, Solution, part b combining the individually incompletely effective fixsrcip and force_bind together, to be more completely effective.


And beyond that, Solution, part c will be necessary gateway iptables changes to make the whole work.

Suggestions/enhancements most certainly welcome. Especially for anything suggested that’s actually inadvertently rather ‘dumb’ -particularly, from a whonix community / purpose perspective. Especially anything that pertains to where best to place / plug in this stuff for other whonix users so interested, to find.

Working notes … continuing …

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.
    .
    .
    .
    So, for 2 - VPN. From a trusted provider.

Aside from using a VPN, the particulars of effecting non-tor traffic on whonix will be discussed another time. It will likely involve iptables rules, routing, and perhaps even policy based routing.

For 1, the challenge of identifying particular traffic so it may be constrained as desired, outside of tor, yet within the vpn (else one wouldn’t be using whonix at all) …

Solution, part a: Create and use an additional interface, and associated IP address, and thus provide breadcrumbs by which the whonix gateway can identify, permit, and route, particular traffic, and only that particular traffic, directly to the VPN.

One way to do this would be to create an additional virtualbox, internal network only, interface on both the whonix workstation, and gateway.

However, I instead propose creating a virtual interface on workstation only. …

{Creation of br0 …}[/quote]

Continuing here with Solution, part b: Constraining a program / application’s IP traffic to a designated address …

I have combined / expanded / ‘enhanced’ the individually incompletely effective fixsrcip and force_bind together, creating runfromiptcpudp

Usage: runfromiptcpudp {ip address} {program}
e.g., per prior post: runfromiptcpudp 192.168.2.1 qbittorrent

Having pinned the program to an ip, traffic is corralled, and part c, what to do with the now identified traffic, can proceed.

Enhancements include:
- exiting if the specified IP doesn’t exist on an interface (rather than proceeding anyways!).
- more verbosity / better syslog’ging whereby a user can figure out what all a program is doing / IPs being used.

Degradation includes:
- fixsrcip is not IPv6 aware, while force_bind is. However, although the runfromiptcpudp combination doesn’t remove that awareness, it has not yet been extended to the fixsrcip base. Thus, until such experts apply their expertise to the code, IPv6 traffic is denied. (Which some may agree is no bad thing.)

Consequences include:
- traffic that escapes a program is either denied, or gets handled and appropriately scrubbed by the current whonix facility. e.g. Despite being so pinned, ktorrent leaks traffic (being a KDE program) - which still gets tor’ified.
- local network broadcasts get muted. (Since they become bound to an IP, not 0.0.0.0).
- A program is independently network encapsulated, without the overhead of LXC, and traffic sysloggable. Providing, consequently, an independent trapping / logging mechanism for 3rd party programs.

To make use of / install:

$ mkdir ~/local/src; cd ~/local/src
$ git clone GitHub - rAntOCauDgb/runfromiptcpudp: Constrain a (Linux) program to use a designated IP address (and, thus, interface).
$ ./INSTALL #(which merely calls make; make install.)

Having set up br0 as per prior message in this thread:

runfromiptcpudp 192.168.2.1 {program}

And traffic is corralled, as desired.


Next up, Solution, part c will be necessary gateway iptables changes to make the whole work.

Working notes … final.

[quote]whonix, torrents, and being a good tor citizen

There are 2 issues:

  1. Identifying / corralling net traffic.
  2. Proxying (udp / socks5) / anonymizing such traffic.

    So, for 2 - VPN. From a trusted provider.

For 1, part a, identifying particular traffic and constraining as desired, runfromiptcpudp as discussed.
[/quote]

Concluding here with 1, Solution part b: Permitting and appropriately routing the designated traffic.

Note: Presented is a way of whonix, torrents, and being a good tor citizen. Proof of concept. Only. Although the steps and details are correct, the specifics of implementing them are suitable only for individual experimentation and use. For general use or implementation, a more robust installation would be required. See Bolt on for whonix_firewall - best place to put files? for such beginnings, and particularly Dev/Firewall Refactoring.

Environment: For the purposes of development / proof of concept, whonix_firewall was ‘cloned’ (and gutted) to whonix_firewall-post, and associated /etc/whonix_firewall-post.d directory clone of /etc/whonix_firewall.d created.(Thank you Patrick!) Specifics can be seen at whonix-torexceptedtraffic_proofofconcept Only the summary / details are shown below.

Assumption: Appropriate settings placed in a file in /etc/whonix_firewall.d, as per /etc/whonix_firewall/30_default, settings such as ‘50_user.conf’:
VPN_FIREWALL=1
VPN_SERVERS=“10.0.1.2”
VPN_INTERFACE=tun0
LOCAL_NET="
127.0.0.0-127.0.0.24
192.168.2.1-192.168.2.1
10.152.152.0-10.152.152.24
10.0.2.2-10.0.2.24
"

On Whonix Gateway:

Preparation:
(1) /usr/local/bin/whonix_firewall-post - essentially just the top part of whonix_firewall, the sourcing and executing of files within a designated .d directory.
(2) /etc/whonix_firewall-post.d/30_lastrules_to_envvars - essentially just the environment variables of whonix_firewall, -and- the storing of the last / dropping rules of each chain, so that iptables changes can be modularly implemented.

  • Each .d file utilizes a lock file so it can’t run twice / double iptables rules.

e.g.:
# Delete old iptables INPUT last rule.
$iptables_cmd -D $IPT_FILTER_INPUT_LASTRULE

< insert appropriate iptables script lines for this module >

Reapply old iptables INPUT last rule.

$iptables_cmd -A $IPT_FILTER_INPUT_LASTRULE

Note: This is NOT how whonix would implement this facility. This mechanism is only useful during the process of development / debugging / discerning correct steps. See Bolt on for whonix_firewall - best place to put files? and/or Dev/Firewall Refactoring for a better implementation mechanism.

/etc/whonix_firewall-post.d/70_torexcept:
iam=$(basename $BASH_SOURCE)
mylockfile=/run/lock/WFP_${iam}_run

if [ -e “$mylockfile” ]; then
echo ; echo $iam already run, lockfile $mylockfile present. Returning without running.
return 0
fi

echo ; echo Running $iam, setting lockfile ${mylockfile}.
touch $mylockfile

whonix_firewall permits multiple VPN servers to be specified, space separated.

iptables, OTOH, requires the servers to be comma separated.

VPNIPS=“${VPN_SERVERS// /,}”
echo -e “\nExtrapolating VPN IPs of ‘$VPNIPS’ from ‘$VPN_SERVERS’.\n”

For the moment, put in log entries … skipped for the purposes of this forum thread.

Note that iptables -t nat INPUT, OUTPUT, and POSTROUTING, default to accept.

- note that -t nat OUTPUT RETURNS if uid cleanet.

Note: whonix_firewall INPUT rules:

- drop all weird/erroneous things

- accept all in from lo

- accept all established

- deny all icmp

- allow all in from tun0

- drop all (last rule)

set -v -x

----------------------------------------

Delete current iptables INPUT last rule.

$iptables_cmd -D $IPT_FILTER_INPUT_LASTRULE

{Placeholder Line: Turns out no rules needed. Logging rules in ‘source’ file handy.}

Reapply old iptables INPUT last rule.

$iptables_cmd -A $IPT_FILTER_INPUT_LASTRULE

---------------------------------------

Note: whonix_firewall FORWARD REJECT all (last rule)

---------------------------------------

Delete current iptables FORWARD last rule.

$iptables_cmd -D $IPT_FILTER_FORWARD_LASTRULE

$iptables_cmd -A FORWARD -i $INT_IF -o $VPN_INTERFACE -s $XCEPTIP -j ACCEPT
$iptables_cmd -A FORWARD -i $VPN_INTERFACE -o $INT_IF -d $XCEPTIP -j ACCEPT

Torrents want to talk to VPN server (presumably) to open ports for

forwarding. (*1)

$iptables_cmd -A FORWARD -i $INT_IF -s $XCEPTIP -d $VPNIPS -j ACCEPT

Reapply old iptables FORWARD last rule.

$iptables_cmd -A $IPT_FILTER_FORWARD_LASTRULE

---------------------------------------

Note: whonix_firewall OUTPUT rules:

- reject all weird/erroneous things

- accept all to tun0

- accept all established

- accept all LOCAL_NETS

- accept all to vpn server ip

- accept all from clearnet userid

- reject all (last rule)

---------------------------------------

Delete current iptables OUTPUT last rule.

iptables -D $IPT_FILTER_OUTPUT_LASTRULE

{Placeholder Line: Turns out no rules needed. Logging rules in ‘source’ file handy.}

Reapply old iptables FORWARD last rule.

$iptables_cmd -A $IPT_FILTER_OUTPUT_LASTRULE

---------------------------------------

Note: whonix_firewall -t nat PREROUTING rules:

- redir (incoming) eth1 tor/9xxx ports to self (tor) equivalents.

- redir eth1 udp/dns to self (tor) :5300

- redir eth1 tcp to self: 9040 (tor) (last rule)

---------------------------------------

Delete old iptables -t nat PREROUTING last rule.

$iptables_cmd -t nat -D $IPT_NAT_PREROUTING_LASTRULE

$iptables_cmd -t nat -I PREROUTING -i $INT_IF -s $XCEPTIP -j ACCEPT

Reapply old iptables -t nat PREROUTING last rule.

$iptables_cmd -t nat -A $IPT_NAT_PREROUTING_LASTRULE

---------------------------------------

Note: whonix_firewall -t nat INPUT rules: none.

- Default ACCEPT, so won’t be in any way.

Note: whonix_firewall -t nat OUTPUT rules: none.

- Default ACCEPT, so won’t be in any way.

Note: whonix_firewall -t nat POSTROUTING rules: none.

- Default ACCEPT, so won’t be in any way.

---------------------------------------

Delete old iptables -t nat POSTOUTING last rule.

- except … it doesn’t currently have any rules.

$iptables_cmd -t nat -D $IPT_NAT_POSTROUTING_LASTRULE

iptables -t nat -A POSTROUTING -o $VPN_INTERFACE -s $XCEPTIP -j MASQUERADE

See (*1).

$iptables_cmd -t nat -A POSTROUTING -s $XCEPTIP -d $VPNIPS -j MASQUERADE

Reapply old iptables -t nat POSTROUTING last rule.

$iptables_cmd -t nat -A $IPT_NAT_POSTROUTING_LASTRULE

---------------------------------------

set +v +x
echo

Enable forwarding.

echo -n "/proc/sys/net/ipv4/ip_forward \(forwarding\) was: "
cat /proc/sys/net/ipv4/ip_forward
echo 1 > /proc/sys/net/ipv4/ip_forward
echo -n "/proc/sys/net/ipv4/ip_forward \(forwarding\) now: "
cat /proc/sys/net/ipv4/ip_forward

return 0

To effect: $ sudo whonix_firewall-post


Complete and more extensive details can be seen at whonix-torexceptedtraffic_proofofconcept

fini


Comments, suggestions, welcome.