Opened 7 years ago

Closed 4 years ago

#873 closed defect (wontfix)

Port changing .. obscurely

Reported by: DISABLED Owned by: zzz
Priority: minor Milestone:
Component: router/transport Version: 0.9.4
Keywords: firewall Cc: killyourtv@…
Parent Tickets: Sensitive: no

Description

Ports changed for anonymity, duh.
UDP port: 1234
TCP port: 1234

All goes well until suddenly "Firewalled" appears (sporadically).
I then changed my UDP *and* TCP port temporarily. I change back for the firewall rules. I have to do this to reset the testing crap. IDK. This then restores the I2P status to "Network ok". yay.
After some time, this happens:
UDP port: 1234
TCP port: 1234 BUT: "Use the same port configured for UDP (currently temporary port)"

Perhaps I'm explaining badly but..
The port for TCP/UDP will sometimes change even when it shouldn't resulting in fuckups with firewall rules.

Subtickets

Change History (15)

comment:1 Changed 7 years ago by Eche|on

First: I2P tests on its own, if ports are reachable or not. If I2P cannot reach a port, it tells you: firewalled/closed. A dozen reason could apply to it, not all are based on your firewall.
Second: If you change something like the port, IP, or any other real advanced config, you need to restart I2P afterwards or your change is not applied.
With laptop mode activated, I2P does choose a new port on every restart.
With config file not read/writeable, new port is choosen, to.
Check your logfiles.

comment:2 in reply to:  1 Changed 7 years ago by DISABLED

Replying to echelon:

First: I2P tests on its own, if ports are reachable or not. If I2P cannot reach a port, it tells you: firewalled/closed. A dozen reason could apply to it, not all are based on your firewall.
Second: If you change something like the port, IP, or any other real advanced config, you need to restart I2P afterwards or your change is not applied.
With laptop mode activated, I2P does choose a new port on every restart.
With config file not read/writeable, new port is choosen, to.
Check your logfiles.

I'm not so sure about that. If I grep my i2p config directory for the port that is supposedly UDP (which is not the one I've configured), I actually see it as "i2np.udp.port=…..".
i2p says it is doing a "soft restart" and it HAS changed my ports.. doesn't make sense that I'd have to restart after that manually.

comment:3 Changed 7 years ago by killyourtv

Cc: killyourtv@… added

I've had the port change "back in the day" because of a seedless bug that prevented I2P from shutting down properly. I2P was hung so I killed it from the terminal. On the next start the port was different. That was back in 2011. It never happened again.

Also: make sure that both instances were started by the same user (i.e., be sure that the first time I2P wasn't started as a service then later as 'you' or a different user account). Sometimes users will configure I2P to run as a service and set up the ports accordingly but are baffled when I2P is run later as a regular user.

I'm not saying either of these scenarios are applicable to your case but maybe these will be useful for others.

comment:4 in reply to:  3 Changed 7 years ago by DISABLED

Replying to killyourtv:

I've had the port change "back in the day" because of a seedless bug that prevented I2P from shutting down properly. I2P was hung so I killed it from the terminal. On the next start the port was different. That was back in 2011. It never happened again.

Also: make sure that both instances were started by the same user (i.e., be sure that the first time I2P wasn't started as a service then later as 'you' or a different user account). Sometimes users will configure I2P to run as a service and set up the ports accordingly but are baffled when I2P is run later as a regular user.

I'm not saying either of these scenarios are applicable to your case but maybe these will be useful for others.

Hm. I have Seedless. I didn't try shutting down I2P or anything though(?).
I'm also running i2p as the same user every time.
If it helps at all, I think this behavior began around 0.9.3..
It's not critical but pain in the ass.

comment:5 Changed 6 years ago by zzz

Component: unspecifiedrouter/transport
Milestone: 0.9.50.9.6
Owner: set to zzz
Status: newaccepted

Yeah, there's a lot of changes in 0.9.3 that affect handling of firewalls that change ports. This is the scenario where it's e.g. port 7777 internally but 1234 externally, then later it changes to 1235, 1236, … especially on UDP.

Before 0.9.3 it caused a lot of problems with reachability. I think, for the most part, routers trying to connect to or get a connection from another router that has this kind of firewall work ok. And for the router with that firewall, it mostly works… but there are clearly still some problems. It shouldn't even try to change its internal port to match. And there may be some UI tweaks to do also. I'm not sure whether the port-changing is only for outbound, or what… whether it will actually accept an inbound UDP connection on the original port or not… or whether we should be announcing the port in the netdb…

After the 0.9.3 changes, you can see how many port-hoppers there are in the netdb (you'll see them as their ports are outside the normal 9000-31000 range) … it's a lot, this is a common type of firewall.

Perhaps you (OP) may help us understand the behavior of this type of firewall.

To be researched further and fixed.

comment:6 Changed 6 years ago by zzz

Copied from http://zzz.i2p/topics/109?page=2#p6518


SSU knows about internal and external port, they may be different because of NATs.

A few releases back, I realized it wasn't tracking the external port correctly, and that it was a big problem because the SSU session handshake includes a signature sent by Bob based on Alice's external port. If Alice doesn't know her port the sig check fails.

So I fixed that up and that really helped SSU connections.

Unfortunately there's some NATs that change external port a lot, or change them for every UDP "connection". The latter is what we call symmetric NAT. I think what the code does poorly now is:

1) Not recognize the difference very well
2) Try to change the internal port to match the external port, at least on next restart, which is counter-productive.

comment:7 Changed 6 years ago by zzz

Several fixes in 0.9.5-21 rev 17371fd6f9ef94bbb60a66c6bacb6828d6a4cde5

  • Bind SSU to configured internal, not external, port at startup
  • Use only internal ports for UPnP (getRequestedPort() fixups)
  • Don't have NTCP follow frequent SSU port changes
  • Don't use external SSU port for internal NTCP port
  • Display internal SSU port on /confignet

The NAT type, sequence of events, and root cause in the OP aren't clear. However the above changes should prevent several cases where internal ports were "following" external ports of a NAT.

Leaving ticket open for testing.

comment:8 in reply to:  7 Changed 6 years ago by DISABLED

Replying to zzz:

Several fixes in 0.9.5-21 rev 17371fd6f9ef94bbb60a66c6bacb6828d6a4cde5

  • Bind SSU to configured internal, not external, port at startup
  • Use only internal ports for UPnP (getRequestedPort() fixups)
  • Don't have NTCP follow frequent SSU port changes
  • Don't use external SSU port for internal NTCP port
  • Display internal SSU port on /confignet

The NAT type, sequence of events, and root cause in the OP aren't clear. However the above changes should prevent several cases where internal ports were "following" external ports of a NAT.

Leaving ticket open for testing.

I shall test with 0.9.5-21 build. It may take some time before I am aware of any result. The issues can arise within varying time slots. I have observed occurrences within hours, days and weeks.

zzz, do you believe this issue effect other users greatly also??

comment:9 in reply to:  description ; Changed 6 years ago by DISABLED

Replying to guest:

All goes well until suddenly "Firewalled" appears (sporadically).
I then changed my UDP *and* TCP port temporarily. I change back for the firewall rules. I have to do this to reset the testing crap. IDK. This then restores the I2P status to "Network ok". yay.

This happened again. The solution (as described in the OP) fixed it (port hopping to a temporary port and back again). The TCP/UDP ports listed on the console were correct (additionally; the TCP port matched the UDP port).

I saw nothing of use in the log files (or anything relevant). I will continue testing and reporting back if anything new is discovered.

comment:10 in reply to:  9 ; Changed 6 years ago by DISABLED

Replying to guest:

Replying to guest:

All goes well until suddenly "Firewalled" appears (sporadically).
I then changed my UDP *and* TCP port temporarily. I change back for the firewall rules. I have to do this to reset the testing crap. IDK. This then restores the I2P status to "Network ok". yay.

This happened again. The solution (as described in the OP) fixed it (port hopping to a temporary port and back again). The TCP/UDP ports listed on the console were correct (additionally; the TCP port matched the UDP port).

I saw nothing of use in the log files (or anything relevant). I will continue testing and reporting back if anything new is discovered.

Upon yet another "Firewalled" error, I port hopped but to no avail. Checking my router.config, I see "i2np.udp.port" describing the "temporary" port I jump to and "i2np.udp.internalPort" describing the permanent (and "normal") port. Whelp.

comment:11 in reply to:  10 ; Changed 6 years ago by zzz

Replying to guest:

Upon yet another "Firewalled" error, I port hopped but to no avail. Checking my router.config, I see "i2np.udp.port" describing the "temporary" port I jump to and "i2np.udp.internalPort" describing the permanent (and "normal") port. Whelp.

Thanks for the testing and report. That's about what I expected from changes in 0.9.5-21 rev 17371fd6f9ef94bbb60a66c6bacb6828d6a4cde5.

It seems pretty clear that you have a "symmetric NAT" - see http://en.wikipedia.org/wiki/Network_address_translation for a description. What I didn't make clear is that I2P can't really deal with them and can't open them up. The changes in -21 only help us deal with it better internally. But we don't even have a proposal for how to implement symmetric NAT traversal.

What -21 did not do is improve the detection so that it throws the internal state to 'symmetric nat' and displays that error in the console.

comment:12 in reply to:  11 Changed 6 years ago by DISABLED

Replying to zzz:

It seems pretty clear that you have a "symmetric NAT" - see http://en.wikipedia.org/wiki/Network_address_translation for a description. What I didn't make clear is that I2P can't really deal with them and can't open them up.

This means I'm outta luck, it'd seem. I could enable UPnP on my router although it isn't desirable nor am I sure if it'd help. I don't believe everyone with this problem may have UPnP as an option, anyhow.

What now?

comment:13 Changed 6 years ago by zzz

Milestone: 0.9.60.9.9

You could just forward that port manually on your router.
You could turn on UPnP and see if it does help

In a quick check in my netdb, I see about 4% of routers have a port 1024-1100 (probably a symmetric NAT?) and another 4% 1101-8886 (maybe symmetric?) and 7% 30778-65535 (maybe symmetric?). So it's a widespread issue.

There are enhancements we could make to the introduction sequence http://www.i2p2.i2p/udp
to deal better with a port hopper. It would take some time to analyze and design.

In the meantime, I'm working on IPv6 support. While people that are NATted are unlikely to have a direct IPv6 address, a free tunnel broker like freenet6 would provide a solution… at a cost of some higher latency.

So I don't see any short-term fix on the I2P side. We can start designing a solution but probably can't work on implementation until we are done getting IPv6 merged and working.

comment:14 Changed 5 years ago by str4d

Keywords: firewall added
Milestone: 0.9.9

comment:15 Changed 4 years ago by zzz

Resolution: wontfix
Status: acceptedclosed
Note: See TracTickets for help on using tickets.