Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
∞ take a peek at our legendary cryptostorm_is twitter feed if you're into that kind of thing ∞
Ξ we're rolling out voodoo network security across cryptostorm - big things happening, indeed! Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit GitHub Ξ

i2p sessions whilst on-cstorm: working thread

To stay ahead of new and evolving threats, cryptostorm has always looked out past standard network security tools. Here, we discuss and fine-tune our work in bringing newly-created capabilities and newly-discovered knowledge to bear as we keep cryptostorm in the forefront of tomorrow's network security landscape.
User avatar

Topic Author
Posts: 1492
Joined: Sun Dec 16, 2012 6:34 am

i2p sessions whilst on-cstorm: working thread

Postby Pattern_Juggled » Fri Jan 23, 2015 7:34 pm

This is an issue being concurrently discussed over at the i2p tracker, but I wanted to echo it here as I expect some of our members might have useful feedback and otherwise might not notice the discussion taking place.

Greetings, making an appearance on behalf of the cryptostorm folks.

We're making use of SNAT to transit network traffic out of the private subnet "inside" cstorm, out to the plaintext web. The channel from member machine to the exitnode is UDP encapsulated... but that's essentially transparent to anything inside that tunnel - save for the fact that it can cause unexpected strangeness when naive network performance algorithms that are looking at the world from inside the tunnel can make unexpected & unhelpful assumptions about bandwidth, TTL, and so on because they don't see the physical topology but rather the logical view from within the tunnel (which is not unique to cstorm nor to "VPN" frameworks in general, of course).

I've been reading up on i2p since this bug came up, in fits & spurts, doing my best to be an entree for the rest of the team into this ecosystem. Consider me at best a dilettante thus far - although working to improve from here. We're keep to do some inproxy-style service (in the line of our torstorm.org gadget), so this is both interesting in its own right, and something we're actively working on as a member service extension for Q1 2015. So I'd best stop being quite so much of a n00b, eh? ;-)

At this point, I'm trying to envision exactly what's getting blocked and at what level of the hierarchy of protocols... we certainly transit *everything* in and out across our exitnodes: there's no filtering, firewalling, or other fiddling going on. Not intentionally anyhow.

We do see occasional issues when a given protocol gets impatient about the SNATting or otherwise terminates itself because of some second-order characteristic of the mux'd nature of exitnodes (there's a public IP per "instance" on a given node: boring details if curious found at haf.cryptostorm.org). So in that sense we've got a "shared IP" model... but not any more so than any dhcp'd local network topology, in functional terms.

Session transit bidirectionally at the exitnode happens via NIC interpolation of SNAT relationships between ports and sessions (or "sessions" in the case of UDP). This logic tends to be surprisingly effective in retaining state for members using a given node... even in UDP (which of course isn't really state - but can have some functional equivalence). Occasionally we see conflicts: two folks on one node torrenting via UDP over the exact same port on the same instance, causing others in the swarm to see the two of them as one entity, from outside, and resulting in all manner of packet dumps, retransmits, collisions, etc. But this is fairly rare as we keep instances small in terms of members connected concurrently per instance (certainly less than 100), and not too many things up the OSI stack rely on UDP for state-ish comms (some IM apps can have similar "port collision" issues).

Mostly, stuff works - and the cstorm wrapper over network traffic is effectively transparent. That's our intent and very much our goal, in all such questions: the packets inside the tunnel shouldn't need to know anything about the outer tunnel in order to do their respective jobs.

Things can get weird with DNS queries that try to stay in - or hop out - of the tunnel, for example. And we've a conflicted - mostly horrible - relationship with IP6 packets at this point, so that's an issue. Fragmentation badness can happen if a given local segment is unusually low MTR-capable - but we've put a decent buffer in for that, even so.

That said, these layered topologies can exhibit nontrivial emergent behaviours that I find fascinating to study, but also often frustrating to diagnose. They mostly do ok... but when they don't, even gathering metrics to determine what's not happy can be an ontological challenge. I am sure none of this is new, or particularly challenging, to anyone working hands-on with i2p, but I state it nevertheless to help ensure we ask broad questions and ensure we're not making implicit assumptions about things that might end up proving to be of substantive relevance in finding real-world solutions for members seeking to make use of this layered / dual-wrapped topology.

Insofar as the member's local machine, when on-cstorm, is wanting to think of itself as a router within the context of i2p... yeah, that's a good question. Does it think if itself as having a public IP (the instance IP, on the connected exitnode)? Or, does it use it's private (dhcp'd) within-cstorm address to interact with ip2? That's likely the crux of this question, isn't it?

My hunch, as a dilettante, would be that we need to stick with the private IP and trying to pull the public IP down into the tunnel would end badly... but that's intuition, not a formal analysis. Let the exitnode deal with the translation of that private IP out to a public port:IP pairing... that's what they get paid the big bucks to do! ;-)

Anyhow, rambling - apologies. We'll look forward to feedback and additional data, and we're ready to do what is required to ensure we can support elegantly this use-case scenario.

Cheers :-)

~ pj
...just a scatterbrained network topologist & crypto systems architect……… ҉҉҉

    ✨ ✨ ✨
pj@ðëëþ.bekeybase pgpmit pgpðørkßöt-on-consolegit 'er github

User avatar

Site Admin
Posts: 1096
Joined: Wed Feb 05, 2014 3:47 am

Re: i2p sessions whilst on-cstorm: working thread

Postby parityboy » Fri Jan 23, 2015 9:34 pm


Thanks a lot for posting this here. I haven't had much involvement with I2P (yet) but as far as CryptoStorm connections are concerned, here is my routing table while connected.

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         UG    0      0        0 tun0       *          U     0      0        0 tun0
linux-turing1.c UGH   0      0        0 eth1
link-local      *          U     1000   0        0 eth1     *        U     1      0        0 eth1

This is running in a virtual machine which is bridged onto my local LAN. If I2P is complaining about being firewalled, my guess is that it in some way makes an outbound connection to something, and tells that something to make an unsolicited connection back to the I2P router. When it doesn't receive a response within a given time frame, it assumes that the inbound WAN ports (in this case on the exit node) are blocked (which they are, of course).

We've had similar discussions (here and here) on the CS forums regarding software such as BitTorrent clients ("connectability" issue), eMule ("LowID" issue) and Bitmessage, and indeed if an individual was to set up a Tor node behind CS as either a pure middle relay or a client/relay hybrid, they would likely run into the same issue - the Tor relay would be unable to receive unsolicited, inbound connections from other relays.

Return to “cryptostorm reborn: voodoo networking, stormtokens, PostVPN exotic netsecurity”

Who is online

Users browsing this forum: No registered users and 2 guests