Although autorelay works great when you know the relay-node that any given peer is connected to, discovering the routing to the peer behind NAT might be problematic at times. To elaborate, consider the following.
Peer A is behind NAT, enables autorelay (
ipfs config --json Swarm.EnableAutoRelay true ), then launches the
ipfs daemon announcing the p2p-circuit addresses using Addresses.Announce, as can be confirmed subsequently with:
Now, if peer B knows what relay-node A is connected to, it can simply do:
ipfs swarm connect /p2p/QmRelayAddress/p2p-circuit/p2p/peerIDofA
But, what if peer B doesn’t know the address of the relay-node that A is connected to! It can try to find the relay-address using:
ipfs dht findpeer peerIDofA. In my case at least, this command used to take a lot of time and then output:
Error: routing: not found. Edit: It must be emphasized however, that since updating to go-ipfs v0.9.1 recently, this problem magically disappeared.
Point 2 above won’t be a problem if peer A was guaranteed to always use the same relay, or, if there was a public list of all available relays that B can query for a p2p-circuit to A.
I faced point 2 above while connecting my home computer (behind NAT+Firewall) to my research workstation in my university (also behind NAT+Firewall). To make the connection as easy and reliable as possible I repurposed a universal p2p-port-forwarder, called tunnel, for the special case of IPFS. [You can use
tunnel for any TCP/UDP port forwarding across NAT and Firewalls.]
Connecting to peer A behind NAT/Firewall from peer B also behind NAT/Firewall, is now as easy as:
tunnel ipfs # In peer A’s node.
tunnel peerIDofA # In peer B’s node.
Notice that none of peer A or B need to launch
ipfs daemon .
tunnel takes care of that. Also, peer B doesn’t need to
swarm connect to A manually.
swarm connecting in the background every few seconds to keep the connection to A alive.
To make the connection private, peer A and B can both use a shared secret with the command-line option:
-k secret. Also, besides the usual IPFS_PATH environment variable, the path to a non-default ipfs-repo may be passed using the option
tunnel in this IPFS mode for both file-sharing and pubsub. Worked fine for me. You can also use
tunnel for SSH to a remote node behind NAT, and together with IPFS, you no more need to use SFTP for file-sharing.
I am sharing this here with the sincere hope that this humble project (
tunnel) would be helpful to at least some of you trying to use IPFS from behind NAT. Thanks for your time.