[Just beginning to sink into the nature of this whonix beastie …]
I see there are documents surrounding whonix-/vpn use in the wiki, in the (advanced) security topics.
I get that whonix (TOR) only passes TCP traffic.
And I see that TOR asks that it not be used for bittorrent use, understandably. (However, I don’t see accompanying ‘See {link} regarding such use instead.’)
I also get that the whonix-gateway/-workstation combination establishes a superior ( isolating / compartmentalizing / anonymizing ) platform.
It feels intuitive to me to use whonix-workstation as a base platform, effect vpn (which would to some extent anonymize non-TCP traffic), and have/permit whonix-{x} to pass non-TCP traffic over the vpn (only) / not TOR. Perhaps with restrictions as to the type and range of such permitted traffic.
I get that doing so violates the strictest sense of the purpose of TOR/whonix. (But it seems to me there are more than a few notes discussing how to accomplish such ‘violations’, caveats apply, and buyer beware.)
Are there links or discussions anywhere as to why/not or how to effect this sort of thing?
(The vpn aspects are well laid out, so those aspects are covered.)
To put it short however, it boils down to this: Tor is a network hosted by volunteers, to allow anonymous communication, etc. and straining such a network would only cost precious, rare resources.
For any given thing, e.g. ssh, vpn, there are reasonings and explanations that describe the environment in which things are sitting, and methods and concerns and caveats surrounding enabling different things.
It seems intuitive to set up a vpn and have tor/tcp traffic go down that pipe, AND allow other, e.g. udp, traffic go out too (but not down the TOR pipe) - perhaps on a user selective basis. [Use at own risk / buyer beware cautions applying.]
So I wondered if there were links similar to the ssh or vpn explanations that describe such a setup and the issues of concern surrounding it.
(It’s all very well, and understandable, to say don’t torrent, but it would be useful if there were an accompanying ‘see here’ for suggestions.)
sorry, but it is hard to understand what you are asking. So, do you want to combine a VPN with Tor over Whonix, while still having the ability of routing traffic through the VPN without Tor? Because that could work, depending on where the VPN is used. If the VPN is installed on the workstation, it wouldn’t work as per design all the traffic on the workstation is torrified. If it was installed on the Gateway (to hide the fact that you use Tor) it wouldn’t be possible either, since you are not supposed to do anything with it, other then route traffic. If it was installed on the host, again to hide the fact that you use Tor, it would of course work, as long as you keep the torrenting on the host.
Take VPN out of the question - I expect whether the VPN is before, during, or after, doesn’t impact the answer. (And, just in case … I wasn’t trying to segregate TOR traffic over non-VPN and other traffic over VPN. Assume all traffic will ultimately be VPNed - specifics to be determined later.)
…> TOR traffic goes thisaway →
---------------------^----+
Pipe To World --^-v–|
-----------------------v–+
…> non-TOR traffic goes thataway →
{Pretend the '.'s are hard spaces.}
ip route tcp-tor-traffic gw tor-entry-node
ip route permitted-non-tor-traffic gw 0.0.0.0
Or something, in essence.
[quote=“Ego, post:4, topic:1725”]Tor over Whonix, while still having the ability of routing traffic without Tor?[/quote] (from the workstation).
Actually, I think that’s exactly the question.
[Although not intuitive. i.e. Why use whonix/tor at all if you want to utilize ‘escapy’ traffic in the first place? Answer, whonix appears to be a well thought out platform to leverage from, upon which to add certain also to be permitted well defined traffic. Carrying the assumption that the user is going to take additional protective measures such as a vpn.]
That’s part of what I mean about explanatory documents as surrounds ssh and vpns - as this statement isn’t intuitive. i.e. It was more my impression that all traffic from the workstation was permitted out (to the gateway), it was the gateway blocking all non-TCP traffic, and forcing all TCP traffic down the TOR pipe. No?
OR … is it that only the browser app’s traffic is forced out through the gateway proxy (per the browser app’s proxy settings), and non-browser traffic (such as ping) is controlled by the above (gateway’s iptables) (not the workstation’s)?
OK, (a) why is that / explanatory documentation? (Not do anything to gateway, that is.); (b) VPN is in essence a routing of traffic, so intuitively this seems the appropriate sweet spot to put it.
Was looking to control things on the gateway (probably), as a sort of fire and forget with kill switch - not bring up/down on host. And was looking to do the torrenting from the workstation. (One’s one stop shopping safe / anonymized / compartmentalized workhorse.)
So I’ll summarize:
It seems intuitive to leverage the whonix platform for all its goodness, and selectively permit other traffic by installing additional permissible traffic settings and controls on the routing control platform that the gateway seems to be.
Is there documentation around (much like ssh / vpn examinations) that explores / explains that?
Or … the articles say please don’t torrent over tor, but don’t note links as to how to utilize whonix yet send UPD traffic over non-tor. Are there any?
This question shows me that you seem to not really have read any of the basic documentation for Whonix. The reason Whonix is able to prevent IP leaks is that the only connection to the outside world happens over the gateway. The gateway has access to your network card and uses this access, to connect to the Tor network. Then, it connects with the workstation, which is not connected to the outside world in any direct way. What this does, is make IP leaks almost impossible, since to find out were, which traffic is from it would be necessary to both exploit the gateway and workstation at the same time.
If you did ANYTHING on the gateway, all this protection would be lost and there wouldn’t be any reason to use Whonix at all, as it would then be just a “normal” Debian in a virtual machine, with no extra protection. Also, it wouldn’t be possible, though to basic firewall settings in the gateway preventing it from beeing used in any way more “advanced” then connecting through Tor to route the connection and receive updates.
This is pretty much the whole “thing” Whonix has going for it over other implementations. Please read the following things, because everything has been explained in detail and with sources in the wiki on multiple occasions:
I have indeed read all of this. If my question were answered there, I would not have posed it.
I won’t say I haven’t lost track of some things (thus the gateway / clipboard question D’OH!).
So a response of ‘Did you miss {this link} (this section) part of the documentation?’ (rather than did you read the entirety of the documentation), would be more than fine.
Had I seen the answer, having perused the documentation, I wouldn’t have asked.
[quote][quote]
OK, (a) why is that / explanatory documentation? (Not do anything to gateway, that is.); (b) VPN is in essence a routing of traffic, so intuitively this seems the appropriate sweet spot to put it.[/quote]This question shows me that you seem to not really have read any of the basic documentation for Whonix.[/quote]
Then you have read, not, been shown, VERY wrongly.
This is far too broad and generic. Arguably, this is true of anything used as a gateway. And ignores what intuitively seems to be (correct me if I’ve misunderstood) the whonix-gateway’s special sauce that further massages such traffic into additional anonymity. (Not just through the compartmentalization inherent to such setups.)
By your statement, since one’s typical physical router, or inlining a second one, is essentially equivalent to the virtualbox nat / whonix-gateway combination, merely running torbrowser on any host install is the equivalent to whonix. If that were true, whonix wouldn’t exist / there would be no reason for it to exist - so, whonix is bringing much more than that in the special sauce it brings to the table.
The gateway has access (to a virtual NAT’ting router, not the) network, and CHOOSES to force all that traffic down the TOR pipe.
So what I have asked is how to have it ALSO choose to send certain other traffic down the NON-Tor network.
Yes, but this is true of any such virtual workstation plus gateway combo. While it seemed to me that whonix was providing additional measures beyond those inherent to such a setup. Correct me if I’m wrong / have misunderstood that.
No. That’s far too broad a statement to be credible. Else there wouldn’t be notes, for example, on how to establish ssh, vnc, shared folders, shared clipboard, or any of the other additional bits, examined so excellently in the wiki. (And all I have asked here is if there is an equivalent to allowing UDP traffic out, too.)
OK, so is that all that whonix is? A nice turnkey install of a default debian gateway / workstation combo, pre-seeded with a firefox torbrowser that has its proxy set, and firewalled to only allow TCP connections?
That wasn’t my impression - my impression was that a whole lot of expert thought and opinion had been baked into whonix’s special sauce goodness and poured all over the package. Have I misunderstood?
That doesn’t seem like a credible statement. Manually adding an ip table rule to permit UDP traffic doesn’t seem impossible. Even the ssh documentation notes making firewall rule changes, or poking holes in the inherent virtualbox nat firewall. So evidently it is possible. Ill advised, counter-intuitive, or buyer beware, maybe (thus my question), but not impossible.
That doesn’t feel right / I must really be misunderstanding things.
On that basis, if I vm a stock debian install, add torbrowser, and pipe it through a virtual gateway - I have whonix.
Yet I see proxies, firewall settings, network controls, and much other apparent whonix excellence present, so it doesn’t feel like it’s that simple.
Or I am really misunderstanding things?
Else … like the discussion surrounding ssh, is there similar documentation present that I’ve overlooked that examines the idea of the gateway permitting additional non-TOR/TCP traffic to go out beside (not through) the TOR traffic?
– I’m not saying it’s equally secure, any more than the ssh discussion that notes the risks being taken and buyer beware. But it does seem prudent to leverage all the whonix goodness and open it up a bit, than take a stock Debian install and try to duplicate the innumerable fiddly bits and settings that so much effort effected in whonix.
(Taking a spoke out of the wheel on this special install, not completely reinvent said wheel.)
Pointers to sections within links about surgically removing said spoke?
To answer the main question… What you’re asking for, either a VPN-only-no-Tor tunnel mode is undocumented. Also a most-traffic-Tor-but-some-direct-VPN-without-Tor is undocumented.
What you’re asking for is somewhat instead of a “TorBOX”, if it’s possible to create a VPNBOX.
( Dev/Inspiration - Whonix )
(Not sure you wanted to know this: Once you follow Whonix VPN documentation ( Features and Advantages ) and tunnel user → Tor → VPN → Internet, all UDP traffic from the workstation is encapsulated inside the VPN. It goes user → Tor → VPN → Internet normally. The gateway won’t attempt to block it as there is no point and outside it’s purpose.)
Wonderful pointers to help me sink into and understand the nature of this beastie.
Whonix seems a wonderful platform to start from (lots of heavy lifting / thinking encapsulated within it). Had never encountered / paid much attention to the ideas until a very short time ago - and quickly realized there are many, many, independently moving bits and pieces all in constant independent and inter-related motion. (You don’t know what you don’t know.) Thus my posed question, and desire to leverage all the good thinking behind the environment - before any tweaking, and to go into any such tweaking with eyes wide open. (Like the ssh and other notes - if you do this you risk that. Which let’s me be my own judge as to what and to what extent I am exposed to any particular risk.)
Hold on … if I follow that then maybe there’s a basic misunderstanding I have about the whonix environment.
So I’ll first expand your flow:
whonix-workstation net activity (say UDP) [1] → whonix-gateway traffic massaging [2] → whonix-gateway vpn redirecting daemon (assume vpn here for moment) [3] → { virtualbox virtual nat router [4] → virtualbox host nic [5] → site internet gateway [6] → inet provider network entry [7] → various internet hops [8] → vpn endpoint [9] } → {tor entry nodes … tor exit node} [10] → destination ip [11]
It was my expectation that all non-TOR/TCP traffic stopped at [2] - intentionally so to effect the stated purpose of whonix.
Am I reading you correctly that all traffic flows all the time, and non-TOR/TCP traffic already inherently diverges at [9] - instead of going to [10], the non-TOR/TCP traffic inherently going wherever it naturally would go in any other non-whonix environment?
(Granted, the non-TOR/TCP traffic normally can’t even be generated in the first place, such traffic generating applications not coming installed by default within the whonix-workstation vm.)
The gateway won’t attempt to block it as there is no point and outside it’s purpose.
If that’s true / I’m following that … then that is a / the source of my basic misunderstanding of the environment. It was my understanding / expectation that all such traffic was simply rejected. If it isn’t … I have much more reading to do (which is fine) - you’ve kindly given me the topic / section / link pointers I needed.
I think the confusion is generated by the many possibilities to place a VPN.
VPNs installed in the workstation connect through Tor so or so. Since their traffic content is encrypted, Whonix-Gateway cannot read it. And does not attempt to understand the traffic on that level. There is no kind of deep package inspection. Since the gateway does not - and there would be no point to - hinder the VPN any way… The workstation is free to generate UDP traffic and send it to the VPN. No UDP traffic “really” passed the gateway. Only TCP traffic. And that TCP traffic happens to include UDP.
The Tor exit relay does not get to see the UDP traffic. Only the TCP traffic to the VPN. And the VPN gets to see the UDP traffic. (If that VPN supports UDP, which is a whole different story.)
A VPN on the gateway [or host] does not enable the workstation to transmit any UDP traffic.
[Only if you combine it again with a VPN inside the workstation, but then the VPN on the gateway (or host) does not really matter for this question.]
I am assuming vpn in gateway. (a) vpns typically limit number of simultaneous connections; (b) in a multi-client environment, easier to have the common gateway do the vpn redirecting, rather than having to duplicate the settings on each client. [Mind you, client installs would permit different clients to go to different server endpoints.] In the end, though, the desire is a single point of common vpn (with a kill switch).
Hold on, -workstation traffic is proxied to -gateway. So the -gateway is doing all the acceptance testing and routing. No?
D’OH. I’m mixing browser and non-browser traffic in that. (Perhaps that’s part of my clarity problem.)
Non-browser traffic is just handed (routed) to -gateway by -workstation. (?) So -gateway does know IP and TCP/UDP/ICMP - ah, hold on … you note no deep packet inspection. Yet icmp is clearly blocked by -gateway. Hmmm.
That doesn’t make sense. Unless … are you saying a VPN inherently encapsulates all traffic into TCP traffic? If so … that’s a basic element I have failed to track. D’OH! (This is the whole, nature / establishment of the pipe [tunnel], vs the nature of the traffic sent/tunneled through that pipe.)
But, the whole point of the conversation is to not burden TOR with the UDP traffic. Thus the gateway level of TOR thisaway, non-tor thataway question. Clearly, per prior notes … I’ve (more) reading to do.
[quote] (If that VPN supports UDP, which is a whole different story.)[/quote] Agreed. And agree beyond the scope of whonix. i.e. Whonix isn’t really part of the mix / is outside of the view under this microscope at that point, and there are lots of other resources on the web discussing such.
Again, this is the point of the question. Seems arguable/intuitive that it should. BUT - that it inherently doesn’t is obviously due to the deep thinking that has gone into making whonix the way it is, and for good reasons. Thus the question, and the reading to do. (Thank you.) Just, as surrounds the notes on ssh - not to say there aren’t good reasons for enabling ssh, just noted caveats and buyer beware applies. (Understandably so.)
Agreed. (As long as the -gateway passes it, that is.) Except … one whole point of this thread is to not burden tor with such traffic.
Then ignore it if it’s not about what you expect and see it as additional explanation. I had included several separates lines in my previous post to discuss the different places where the VPN is running. 3 chapters. First chapter, just introduction. Second chapter, VPN on the workstation. Third chapter, VPN on the gateway.
Deep package inspection does not usual firewall rules.
The gateway in a default setup cannot and will not relay UDP. But if there is a VPN on the workstation (!), then workstation UDP traffic can be encapsulated inside the VPNs TCP traffic. That doesn’t violate what has been said before.
The location where the VPN is installed, inside the workstation, on the gateway or on the host changes a lot. That’s what you might confuse.
Ah, sorry. -workstation ‘just’ hands packet to -gateway without further inspection (no iptables munging, no firewall, etc.), while, for example, -gateway does do such things.
[quote][quote]
So -gateway does know IP and TCP/UDP/ICMP - ah, hold on … you note no deep packet inspection. Yet icmp is clearly blocked by -gateway. Hmmm.[/quote]Deep package inspection does not usual firewall rules.[/quote] Ah. OK. Thanks for that clarification.
[quote]The gateway in a default setup cannot and will not relay UDP. But if there is a VPN on the workstation (!), then workstation UDP traffic can be encapsulated inside the VPNs TCP traffic. That doesn’t violate what has been said before.[/quote]Agreed. I think I lost track that a VPN encapsulates UDP traffic within its TCP traffic. My bad.
[quote][quote]But, the whole point of the conversation is to not burden TOR with the UDP traffic. Thus the gateway level of TOR thisaway, non-tor thataway question. Clearly, per prior notes … I’ve (more) reading to do.[/quote]The location where the VPN is installed, inside the workstation, on the gateway or on the host changes a lot. That’s what you might confuse.
[/quote]
I suspect you’re right. I guess I was assuming VPN aspects equivalently applied across all install permutations, and you seem to be saying they don’t. Going back to documents now …
I believe part of my confusion has been because I think of a network flow in terms of a packet’s src/dst ip/ports (and protocol).
Thus (from Combining Tunnels with Tor) “Setting up VPN before Tor {contradicts} (User → VPN → Tor → Internet)”
“(User → VPN → Tor → Internet” says to me (protocol: user src whonix-workstation / random → dst site/service) → (protocol: src whonix-workstation / random → dst vpnsite/service) → (protocol: src vpnsite / random → dst torentry/service) → (protocol: torexit / random → dst site/service. Which feels more like setting up tor before vpn.
– I’ve probably botched the specific writing of that, but hopefully the premise / intent comes through.
The nomenclature is further confused by my inherent understanding/assumption that inherently most traffic presumably stems from torbrowser - which is proxied to Tor. So even that first step is really (protocol: user src whonix-workstation/random → proxied(dst site/service)).
I now see that instead of being a packet’s src/dst ip/ports (and protocol), the nomenclature refers to a packet’s encapsulation, or the tunnels within/through which a packet is flowing. I’m not saying the nomenclature isn’t right/common, but I had to happen to cant my head at it before I realized the different way of looking at it the phrasing.
Had (User → VPN → Tor → Internet) been written instead as something like (Tor ( VPN (User → Site))) I probably wouldn’t have misfollowed the section.
Problem being, because of my assumption of torbrowsed’s web traffic, the above seems like it should actually be (VPN (Tor (User-> Site))).
Not saying not my bad, but am noting the nomenclature may be unclear to any given reader.
