Ensuring other peers can reach me via DHT

Hey guys, I’m trying to understand a few things here.

I want to run a DHT, where certain peers are behind a NAT. I want every peer in the network to be able to find out about and communicate with each other (even ones behind NAT).

According to this post, my understanding is that peers behind NATs can rely on other peers to relay for them. In other words, does this mean that peers behind NATs can still have their address entry present in the DHT routing table, as described here, and that other peers will be able to find them via the DHT?

My questions are:

  • Is AutoRelay enabled by default? If not, how can I enable it?
  • Does AutoRelay work with Kad-DHT out of the box? Or do I need to configure it somehow?
  • If the answer to the above two are yes, then does that mean that the only thing I need to do to get the desired behavior I described is to make sure that DHT server mode is enabled on all peers, including those behind NATs?

Thanks so much for the help :slight_smile:

Hi @smnzhu,

In other words, does this mean that peers behind NATs can still have their address entry present in the DHT routing table

That depends on the DHT you want to use. The IPFS DHT only tracks publicly routable peers. In case your network deploys its own DHT you could have it track non-public nodes. Without knowing much about your use-case, I don’t think that is a good idea though, given that non-public nodes in your routing tables will slow down queries.

I would recommend that you further describe your use-case before I make any recommendation on alternative discovery mechanisms.

I’m having the same questions. In my case:

I’m testing with the example chat-with-rendezvous attached in the go-libp2p repository with 2 remote nodes in following cases:

  • Both two nodes are running with public IPs. OK.
  • Node A is behind a NAT at the meanwhile node B is running with a public IP. From the log, node A announced itself with a local IP (10.0.0.2 in my case), thus node B cannot connected with node A with that address. But node A can still connect to node B with the public IP of node B. Partially OK.
  • Both two nodes are running behind NAT with local IPs. In this case both nodes are announced with local addresses and not possible to connect with each other. They can see each other with the local IPs, but obviously cannot connect with each other on that.

So my question is much similar with @smnzhu 's second one:

  • Does AutoRelay work with Kad-DHT out of the box? Or do I need to configure it somehow?

Thank you for any help and suggestion. :slight_smile:

B.R./Alex

I was planning on using the DHT implementation in go-libp2p-kad-dht. I am only using it for peer discovery within the network atm.

The way things work right now, is that any peer can send certain messages via pubsub to the network, which represent some request for data. Any other peer who sees this message, then needs to be able to connect to the requesting peer to send them the data they requested.

What can I do if the requesting peer is behind a NAT? Will their relay address show up in the DHT, so that other peers can send them a response? Or will they never be able to receive a response to their query?

@mxinden Any updates on this? Thanks!

One thing I’ve come to realize in the last one or two days is that peer discovery using the DHT is not actually based on what entries are present in the routing tables. It appears that the peer address information for each peer is actually stored as entries in the DHT itself.

However, my question still remains: will peer discovery actually “work” properly for peers that are behind a NAT? In other words, if I am behind a NAT, will other peers be able to discover me? and will they be able to connect to me, whether it be via relay or some other means?

The libp2p Kademlia implementation does not track non-public nodes by default.

The way things work right now, is that any peer can send certain messages via pubsub to the network, which represent some request for data.

How about including the relayed address of the peer behind NAT in the pubsub message?