Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nat traversal port selection #383

Closed
whyrusleeping opened this issue Jul 28, 2018 · 4 comments
Closed

Nat traversal port selection #383

whyrusleeping opened this issue Jul 28, 2018 · 4 comments
Labels
exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up

Comments

@whyrusleeping
Copy link
Contributor

I have an ipfs node that is behind a NAT, but I have port forwarding set up.
Despite this, my peer does not advertise any reachable address (it doesn't know about the port forwarding).

I could manually add the right address to my advertised addresses, but forcing users to do that is kindof obnoxious UX.

We should probably have nodes discover their gateways, attach their listen ports to it, and then ask some nat service to try dialing us through it. If that succeeds, then we should add it to our list of known good addresses.

@whyrusleeping whyrusleeping added kind/enhancement A net-new feature or improvement to an existing feature exp/expert Having worked on the specific codebase is important feature P2 Medium: Good to have, but can wait until someone steps up labels Jul 28, 2018
@Stebalien
Copy link
Member

I believe the issue here is that the node is running on freebsd, which doesn't support reuseport. Therefore, it's using random ports when dialing. Unfortunately, that means that we're advertising these random ports.

But yeah, we should do as @whyrusleeping says: figure out which external addresses are reasonable and ask some node to try dialing them. Unfortunately, the current libp2p construction makes this a bit tricky (connection deduplication).

@Stebalien
Copy link
Member

NATs may also be messing with these ports.

Stebalien added a commit that referenced this issue Aug 2, 2018
related to #383

I won't call this *fixed* yet but it should help.
@Stebalien
Copy link
Member

So, my attempted fix was wrong. We already expose the addresses on Host.Addrs.

There are two issues here:

  1. The nat we were testing on was broken. The router reported its internal address as its external address. Fixing this will require some work.
  2. We don't re-announce addresses to the network. That is, we gossip them when connecting to our DHT neighbors but we don't then send these neighbors updated addresses.

@marten-seemann
Copy link
Contributor

This should (partially) be solved by AutoNAT, and more elegantly by AutoNAT v2.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
exp/expert Having worked on the specific codebase is important kind/enhancement A net-new feature or improvement to an existing feature P2 Medium: Good to have, but can wait until someone steps up
Projects
None yet
Development

No branches or pull requests

3 participants