Hosting IPFS node with ngrok

IPFS-NAT-traversal-using-ngrok.md

Hosting IPFS from behind NAT/Firewall using a free reverse proxy (ngrok)

1. Expose localhost's port 4001 to public internet using ngrok: ngrok tcp 4001. Tip: Use -region= flag for lower latency.
2. Note the hostname and port returned by ngrok in the form: tcp://hostname:port -> localhost:4001
3. Open the ipfs config json file ~/.ipfs/config
4. Edit as follows: Addresses.Announce=["/dns4/put-the-hostname-here/tcp/put-the-port-here"]
5. Save the config file
6. ipfs daemon

@avatar-lavventura True. Better use the circuit-relay with hole-punching enabled. I used the ngrok solution only when public relays were not available.

How/where could I enable Swarm.RelayClient.Enabled? Would ipfs config --json Swarm.RelayClient.Enabled true be enough? also will it bring any security concerns?

@avatar-lavventura it ought to be enough if you're using ipfs v0.11.0 onwards. For older versions however you need ipfs config --json Swarm.EnableAutoRelay true. Below I give a list of commands which will cover both new and old versions, while saving your bandwidth.

    ipfs config --bool Swarm.EnableRelayHop false
    ipfs config --bool Swarm.RelayService.Enabled false
    ipfs config --bool Swarm.DisableNatPortMap false
    ipfs config --bool Swarm.Transports.Network.Relay true
    ipfs config --bool Swarm.EnableAutoRelay true
    ipfs config --bool Swarm.RelayClient.Enabled true
    ipfs config --bool Swarm.EnableHolePunching true
    ipfs config AutoNAT.ServiceMode disabled

AFAIK there isn't any more security concerns than making your IPFS node reachable from the public internet entails. Your node might see a rise in bandwidth consumption.

If my node is only connected using ipfs swarm connect <ipfs_id> would all those still be needed?

@avatar-lavventura

ipfs swarm connect <peerID> means you are forming an outgoing connection to the node with peerID. For that you don't need to use relay or ngrok.

But, if you want other nodes to find your node and connect to it (i.e. incoming connections), e.g. to access files pinned by your node, then you gotta give your node a publicly reachable address on the internet. If you don't have a public IP (i.e. you are behind NAT), relays or ngrok will give you such a public IP.

In brief,

1. you want to retrieve files hosted by other nodes - no need for relays or ngrok.
2. you want others to retrieve files hosted by you and you dont have public IP - you need relay or ngrok

Thanks. I don't want other nodes to find me. Basically, I setup a google-instance (which has a public IP and open port, 4vCPU - 8 gb ram ) that runs a ipfs node. And from my laptop I did ipfs swarm connect <peerID> into the google instance. After the connection I was able share ipfs objects but the speed is extremely slow, 5 minutes for 100 mb. I am not sure its because how ipfs works or due to the google instance. While looking ways to improve the data transfer speed, I find myself in your gist.

PS: Respect for your bash-script on https://github.com/SomajitDey/ipfs-chat

@avatar-lavventura

An easy way to make a node undiscoverable by other nodes is to not connect to the DHT at all. To do this either launch your daemon with --routing=none flag or change the ipfs config file. That is to say either

1. ipfs daemon --routing=none or,
2. ipfs config Routing.Type none followed by ipfs daemon

If a node is disconnected from DHT like this, it can still form outgoing connections to other nodes specified with ipfs swarm connect <fully-qualified-multiaddress>. It can also receive incoming connections from other nodes which know its own multiaddress - i.e. /ip4/<ip>/tcp/<port>/p2p/<peerID>

In case you need to connect to DHT but not publish your multiaddress to DHT, you may either

• make use of Addresses.NoAnnounce
• or publish a fake address with Addresses.Announce
• or replace 0.0.0.0 in Addresses.Swarm with 127.0.0.1

For further discussions feel free to ask the friendly broader community at https://discuss.ipfs.io/ or their corresponding subreddit.

P.S: Thanks a lot for starring ipfs-chat. You might also be interested in another project I started IPNS-Link for exposing dynamic sites with IPNS as opposed to static ones. Here are two blogs abt it - 1) medium ; 2) dev

@SomajitDey I didn't know ipfs swarm connect /ip4/<ip>/tcp/<port>/p2p/<peerID> is able to connect nodes that are started as ipfs daemon --routing=none thanks for pointing it out. I did:

ipfs init --profile=server,badgerds
ipfs daemon --routing=none

Before ipfs swarm connect /ip4/<ip>/tcp/<port>/p2p/<peerID> I always do nc -v <ip> 4001 to check is the the ipfs running or not.

and I was able share file using ipfs swarm connect /ip4/<ip>/tcp/<port>/p2p/<peerID>, but I did not know I can do it with fully-qualified-multiaddress as well.

I hope ipfs daemon --routing=none will also help to improve slow transfer over LAN. I remember seeing it over here: ipfs/kubo#5037 (comment)

I did not get the In case you need to connect to DHT but not publish your multiaddress to DHT, you may either part. I was directly sharing /ip4/<ip>/tcp/<port>/p2p/<peerID> with the node over a public domain. But I have concerns having IP and port information publicly known info.

@avatar-lavventura

By fully qualified multiaddress, I meant addresses that contain the ip, port and peerID, e.g. /ip4/<ip>/tcp/<port>/p2p/peerID.

If your google node is connected to DHT, your laptop node can get the fully-qualified-multiaddress of the google node from the DHT by referring to its peerID. When google node is not connected to the DHT (--routing=none), the laptop node must be given the full address of the google node by some other means - e.g. you hand typed it into ipfs swarm connect ....

Your multiaddress only becomes public when it is published to the DHT. As long as you remain disconnected to the DHT, your google node is undiscoverable by other nodes. For added safety however you can always use the Private Networks feature. In that way, only your laptop node and google node can connect to each other using a common secret key - forming a private network.

The slow transfer speed beats me. AFAIK, its not a problem with IPFS.

its not a problem with IPFS.

Like it is not problem for the IPFS developers? or slow transfer speed problem was always there for IPFS but accepted as it is?

@avatar-lavventura I meant that I suppose the slow speed is not due to ipfs per se. Because I and some of my colleagues who used ipfs didnt experience very slow speeds once the peers were swarm connected.

Probably there was some issues in the Google instance I am using since 100 MB was downloaded in ~10 minutes even peers were swarm connected.