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.