Page 1 of 1 topological & routing discussions

Posted: Wed Sep 23, 2015 6:27 am
by anony
Thanks for your time, and for being awesome.

I have some questions if you don't mind. Some of the writing is ambiguous; I'm confused about how this works, and the routing...

Is it:
Member >> Core >> Voodoo node >> Core >> internet
Member >> Core >> Voodoo >> internet
Member >> Voodoo >> Core >> internet

Or something like:
upload= Member >> Core >> Voodoo >> Core >> Internet
download= Internet >> Voodoo >> Core >> Member

Or something else?

When you say there's no linear path- do you mean within each session (different outgoing/incoming path), and/or between sessions (like from changing node topology.)?

If this is a 3 hop system, does the tunnelling setup between the core node and the voodoo, somehow avoid some or all of the redundant traffic- otherwise it would seam very inefficient...double bandwidth/half capacity (upload only?).

I understand the general reasoning that adding these nodes is fairly safe, and good for the added resiliency of the network; I feel much less clear on how it works and the potential security/privacy benefits. What is the threat profile that this addresses, and how does it do so?

PS- imho, networkWTF is a far superior name. Voodoo has a lot of hard to overlook negative connotations, even for us atheist types. umm also, what's up with that avatar? blind killer whale out of water?

Re: alpha token batch, official release

Posted: Wed Sep 23, 2015 3:26 pm
by parityboy

The path is User->Voodoo->Core->Internet->Voodoo->Core->User.

The packets pass transparently through the voodoo node onto the core node, and then out to the Internet, however the source IP address of exiting packets is the voodoo node's IP address - this means that the core node only sees the voodoo node IP address when a user initiates a session. Also when sites on the Internet reply, they reply to the voodoo node, not the core node.

I assume then that the reply packets are routed back to the core node via the voodoo node, where they are re-encrypted and routed to the correct user.

Re: alpha token batch, official release

Posted: Thu Sep 24, 2015 11:16 pm
by anony
The path is User->Voodoo->Core->Internet->Voodoo->Core->User.

I don't understand how that could be right... I can follow most of the github server config, though I'm not familiar with exactly how GRE tunnels function.

As I understand it, one of the main objectives of Voodoo is to be able to utilise VPS infrastructure without implicitly trusting it. This necessitates that the VPS's (Voodoo nodes) are not privy to the CS network authentication, nor any un-encrypted data directly between the user and the internet. A VPS is able to safely handle encrypted data between user and the core (such as a proxie'd ovpn tunnel), and/or traffic between the internet and the core. If the initial connection is made through the voodoo node, how can the core respond directly to the user without going back through an existing proxied tunnel though? I'm pretty sure that would require two user network tunnels which doesn't seam feasible with standard ovpn, and wouldn't provide the relevant ip address hiding. I think there may be some confusion as to physical path vs the tunnelled perspective.

If I understand this correctly- it must go back through an existing proxied tunnel, and The route would be:
For clarity
outgoing: User->Voodoo->Core->Internet
incoming: Internet->Voodoo->Core->Voodoo->User

The resulting tunnelled perspective from the User would be:
User->[email protected]>Internet->[email protected]>User
The tunnelled perspective from the Voodoo node would be:
User(encrypted)->Vodoo(forward)->Core; Core(encrypted)->Voodoo(forward)->User; Internet(encrypt/forward)->Core
The tunnelled perspective from the Core would be:
[email protected]>Core(forward)->Internet; [email protected]>Core(encrypted/forwarded)->[email protected])

I've thought/speculated on such a setup, and have comments- but I'll save them until the routing is confirmed or clarified.

voodoo implies there's some spooky magic involved.

Yes, it also sounds cool, and can imply it's powerful, mysterious and imposible to understand- I get that that's what they're going for, and I guess it fits well enough in that narrow context. Except that this is opensource, done openly/transperently- with setup/configs posted for all, and explanation of exactly what it does and how it works- so it's not really that mysterious, or impossible to understand (hard to explain for sure) and there's definatly no magic execpt in a figurative sense. The word also brings the connotations of ignorance and superstition, the people who take advantage of such, and the methods used to do so. For certain religious types it also invokes evil and devil stuff. All that significantly outweighs the narrow positive context in my mind. WTF, although also somewhat ambiguous usually points to something surprising, novel, interesting, hard to understand, and often fucked up. -That sounds exactly like what someone who was trying to analyse an evolved version of this will be thinking.

Re: alpha token batch, official release

Posted: Fri Sep 25, 2015 5:28 pm
by parityboy

You're correct; the last part of the return leg must return back through the voodoo node before hitting the user. So yes, the path is:


The latency must be nasty...

Re: alpha token batch, official release

Posted: Tue Oct 06, 2015 1:06 pm
by df
Still working on it, but it seems stable enough that we'll probably take it out of the testing phase soon.

And FYI, the path is actually:
User->Core->Voodoo->Core->Internet->Core->Voodoo->Core->User->Taco Bell.
Okay maybe I made up that last one..

The whole point of this is to get users more exit IPs by using VPSes without risking any cryptographic keys or auth data by storing that data on a VPS, or risking disclosure of client IPs. If one of these voodoo VPSes gets pwned or the hoster admin gets into it, they'd be able to sniff/hijack plaintext packets the same way any attacker would be able to if they hacked into any one of the hops (routers) between CS and the thing on the internet you're connecting to (or if they directly hacked the the thing on the internet you're connecting to). Or they could drop all encrypted packets in an attempt to force someone to use plaintext. That's why it's always a good idea to keep an eye on any instabilities in your internet, as it could possibly be an attack (like suddenly being able to only reach HTTP sites and not HTTPs).

The other benefit here is that this setup will make correlation attacks much harder. Even if an attacker gets access to the voodoo VPS, they won't be able to retrieve any real client IPs.
For example, when I connect to the VPN using the Indonesian voodoo instance (named "tahu") and locally run a `ping`, tahu sees:
[[email protected] ~]# tcpdump -ni any host
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
14:18:58.988574 IP > ICMP echo request, id 1, seq 1586, length 40
14:18:58.988602 IP > ICMP echo request, id 1, seq 1586, length 40
14:18:59.007800 IP > ICMP echo reply, id 1, seq 1586, length 40
14:18:59.007813 IP > ICMP echo reply, id 1, seq 1586, length 40

Keep in mind that some confusing POSTROUTING SNAT via iptables is happening here, which tcpdump doesn't see since it's happening at a point in the kernel after tcpdump gets/displays the packets.
So although it appears as though google's public DNS just responded to the non-internet accessible IP, trust me that it didn't :)
The packet's source gets rewritten before it goes out and the duplicate packet is dropped.
I've verified this by running tcpdump on another server and pinging it locally (while logged into tahu), and it does in fact only get the one ping request.
Anyways, thanks to the GRE tunnel between the core and the voodoo nodes, the voodoo node can talk (send packets to) a VPN client on the core using this 10.whatever IP without having to know the real, internet accessible IP of the client.
That means the only way a correlation attack would be useful when hacking the voodoo node is if the attacker can also get you to goto a page that discloses your VPN IP (by exploiting the WebRTC/STUN vuln, for example).

The final idea here is still to have the user first connect to a "jump" or "entry" VPS node. All the entry node would do is forward packets to the core. Since the packets are encrypted by OpenVPN on the client-side, and the decryption only happens by OpenVPN on the core, the entry VPS never gets access to anything that would make decryption possible.

So with that final setup, pwning the entry would be pretty much useless as the most you could do is see all the IPs of the people trying to use it, but you wouldn't be able to cross reference that with destination IPs since you can't tell what the final destination IP is (or you could block all packets, but that would just prevent someone from using that entry node, and they would hop onto the next one). pwning the voodoo VPS would mean the same thing, but reversed (you can see where packets are going but not where they're coming from).

I hope that answers some of your questions :-)

Re: alpha token batch, official release

Posted: Tue Oct 06, 2015 4:04 pm
by parityboy

Silly question, but if the outbound path is


and the return path is


how does that increase the number of exit IPs, when the public Internet sees the Core node's IP address?

Re: alpha token batch, official release

Posted: Tue Oct 06, 2015 7:46 pm
by df
Because of the way the GRE tunnel is setup, it allows the core to use the voodoo node's IP as the exit IP. Pretty sure it's a form of spoofing, but hey, it works :-P

It's similar to, although that setup is designed to protect a server from DDoS by using GRE along with a BuyVM VPS so webservers or whatever can be accessed by using the BuyVM IP instead of the real server's IP. Our setup uses more layers to make the concept work in reverse and in an OpenVPN NATting compatible way, but that page was very useful for me when I first started testing out this idea. If you're curious, some of the other pages that helped me think of ways to get voodoo functional are: ... nux-router ... gre-tunnel ... herez-gre/

Re: alpha token batch, official release

Posted: Mon Nov 23, 2015 7:54 pm
by DudeOfLondon
So the ip that is reported by "what is my ip address"-websites is the ip of the "voodoo"-sub-node.

And you write, that the subnode can be everywhere in the world. But how can I use geo-ip restricted services then, if the subnode is chosen randomly?

Is there still a server list, that you would chose from? I guess not.

Re: alpha token batch, official release

Posted: Fri Feb 05, 2016 11:53 am
by df
The lifetime token is called an "aleph". In this forum post PJ was calling the first voodoo tokens "alpha" as in "the first ones". Yea, that is confusing. Poor choice of terms I guess :-P

Anywho, the only documentation on "voodoo" is what you find on this page and the technical details I wrote up on ... /

The "for [semi-]dummies" summary:
Using voodoo allows us to help prevent correlation attacks, and let's us use VPSes as end points for the VPN (which means more exit IPs to choose from) without having to expose any sensitive data to the VPS. This is a good thing because VPSes are mostly dirt cheap, where as the dedicated servers CS uses are very expensive.

Paraphrased from that github link above:
"Half voodoo" = you -> core dedicated server -> exit VPS -> internet
"Full voodoo" = you -> entry VPS -> core dedi -> exit VPS -> internet

In "Half voodoo", the "core dedi" sees where you're coming from but not where you're going to, and the exit VPS sees where you're going but not where you're coming from.

In "Full voodoo", the entry sees where you're coming from, but not where you're going to, the core doesn't see where you're coming from or where you're going, and the exit VPS sees where you're going but not where you're coming from.

Check out ... / for more information (skip the sections with the commands if you want, they're mostly there as a reference anyways).

Re: alpha token batch, official release

Posted: Thu Apr 07, 2016 8:28 am
by df
Yea, similar to Tor relay chains.
And yes, VPNs can be attacked. Anything online can be attacked (and probably is being attacked), and a lot of offline stuff too.

Voodoo is something the CS-team invented, but it does use existing networking technologies, just in an unusual way :-)