Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1441 closed defect (invalid)

I2P complains about firewalled ports over cryptostorm VPN

Reported by: str4d Owned by: zzz
Priority: minor Milestone: undecided
Component: router/transport Version: 0.9.18
Keywords: firewall Cc:
Parent Tickets:

Description

Reported by ThatBrickster on Twitter.

I2P works fine, but complains about being firewalled. cryptostorm say that they aren't Symmetric NAT and they support all protocols/ports transparently. So I2P should not be complaining.

cryptostorm does squash IPv6 packets (for being leaky), and they thought that this was the cause (thinking that I2P relied on IPv6). This shouldn't have any effect on the firewalled status, because IPv4 inbound should work.

We should test this. cryptostorm are open to making I2P work, so if it *is* a problem on their side they will likely fix it. And if it's a problem with our firewall detection code not playing nice with VPNs, we should fix that.

Subtickets

Change History (10)

comment:1 Changed 4 years ago by zzz

The firewall detection code should be IPv4-only. I don't think IPv6 is the issue.

comment:2 Changed 4 years ago by zzz

Need clarification. Is I2P reporting "firewalled" or "symmetric NAT"?

comment:3 Changed 4 years ago by bricky149

It comes up as 'firewalled' when connected to CS.

comment:4 Changed 4 years ago by zzz

ok thanks. The first place to start is to see if I2P is detecting your IP correctly. It will tell you in the console on /confignet under 'TCP Configuration'.

Does cryptostorm give you an interface with a private or a public IP? Could I2P be getting confused by a local UPnP gateway?

Also please provide version information from the op of /logs

comment:5 Changed 4 years ago by cryptostorm

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

comment:6 Changed 4 years ago by zzz

What we seem to be missing here is any information from somebody actually running I2P + Cryptostorm, so all we are doing is guessing.

Once we do get that, it should be pretty straightforward.

First, as requested in comment 4 above, is I2P correctly detecting its public (VPN'ed) IP?

If not, then got to fix that, either by disabling UPnP in I2P, or hard-configuring it, or something else.

If so, then figure out why I2P isn't getting inbound connections on that IP, leading to the "firewalled" indication.

comment:7 Changed 4 years ago by cryptostorm

We've not yet verified this bug via our own testing, and are acting on the basis of reported issues by a network member - which is perhaps not ideal.

Presently we're provisioning one of our development servers as a test-bed for i2p/cstorm functionality. I've opened a reminder in our internal task-tracking system to report back tangible results from those initial tests to this bug report, with details, so we can validate (or disconfirm) the reported issue here.

comment:8 Changed 4 years ago by bricky149

  • Status changed from new to testing

Small update, a change of router was required to get it working for me. I2P also works natively over CStorm's network now. Will leave open for testing.

comment:9 Changed 4 years ago by bricky149

  • Status changed from testing to needs_work
  • Version changed from 0.9.17 to 0.9.18

Nah, jumped the gun here. I must have seen I2P not update its network status while connecting to CryptoStorm?. At first it says it's okay until a few minutes later, then it complains about being firewalled.

comment:10 Changed 4 years ago by bricky149

  • Resolution set to invalid
  • Status changed from needs_work to closed

Still have no idea, probably some config error on my end. Resolving as invalid since it may not be an I2P problem.

Last edited 4 years ago by bricky149 (previous) (diff)
Note: See TracTickets for help on using tickets.