Unable to holepunch from the local network to a Docker container

[louneskmt]

Hey!

I am not able to connect to a DHT server running in a Docker container, from the same local network. To be clear, the Docker stack has its own Docker network, which lives in my home network. Here is a summary of the situation (I used @hyperswarm/doctor for the tests):

Apparently, it may be because as both the clients and the server have the same external IP X.X.X.X, it tries to connect via LAN, but in reality the server is in a container with its own network.

Here is the full error, client-side

Waiting for node to be fully bootstrapped to collect info...

Node info:
- remote host: X.X.X.X
- remote port: 56888
- firewalled: true
- nat type: consistent

Connecting to test server...
Sending 32 bytes for the server to echo
/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/connect.js:154
  const onabort = () => c.encryptedSocket.destroy(HOLEPUNCH_ABORTED())
                                                  ^

DHTError: HOLEPUNCH_ABORTED: Holepunch aborted
    at Holepuncher.onabort (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/connect.js:154:51)
    at Holepuncher.destroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/holepuncher.js:279:31)
    at Holepuncher._autoDestroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/holepuncher.js:267:31)
    at Holepuncher._consistentProbe (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/holepuncher.js:218:10)
Emitted 'error' event on NoiseSecretStream instance at:
    at WritableState.afterDestroy (/home/louneskmt/test/node_modules/.pnpm/streamx@2.12.5/node_modules/streamx/index.js:444:19)
    at NoiseSecretStream._destroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+secret-stream@6.1.0/node_modules/@hyperswarm/secret-stream/index.js:463:5)
    at WritableState.updateNonPrimary (/home/louneskmt/test/node_modules/.pnpm/streamx@2.12.5/node_modules/streamx/index.js:189:16)
    at WritableState.update (/home/louneskmt/test/node_modules/.pnpm/streamx@2.12.5/node_modules/streamx/index.js:174:70)
    at WritableState.afterOpen (/home/louneskmt/test/node_modules/.pnpm/streamx@2.12.5/node_modules/streamx/index.js:501:27)
    at NoiseSecretStream._predestroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+secret-stream@6.1.0/node_modules/@hyperswarm/secret-stream/index.js:390:7)
    at NoiseSecretStream.destroy (/home/louneskmt/test/node_modules/.pnpm/streamx@2.12.5/node_modules/streamx/index.js:572:12)
    at Holepuncher.onabort (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/connect.js:154:43)
    at Holepuncher.destroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/holepuncher.js:279:31)
    at Holepuncher._autoDestroy (/home/louneskmt/test/node_modules/.pnpm/@hyperswarm+dht@6.3.3/node_modules/@hyperswarm/dht/lib/holepuncher.js:267:31) {
  code: 'HOLEPUNCH_ABORTED'
}

Node.js v18.12.1

I have been able to make it work by manually setting remoteHolepunchable to false here:
https://github.com/hyperswarm/dht/blob/e2b4cb8588d1954765f176c2f092ecf72966f2d3/lib/connect.js#L139

Received new connection from 172.81.0.1
Connection from 172.81.0.1 was closed 

Thanks!

[mafintosh]

thanks! so you can make it work? Working on a tweak where it tries all methods always which would then do the trick here also

[louneskmt]

Yep, it definitely works as expected using remoteHolepunchable = false!

[LuKks]

@louneskmt could you try this branch? dual-connect-lan

Or if you could let me know how to replicate your setup so I can try it?

[LuKks]

Just tried and works with dual-connect-lan branch!

With current main branch it effectively doesn't work, so this is good as it would be fixed soon!

[cshotton]

My experience has been that the DHT code works as expected (i.e., peers show up correctly inside Docker instances), but the encrypted sockets returned by HyperDHT mistakenly use the first available network interface. Under Docker, that is generally the bridge network and is NOT the desired interface to use when talking to the outside world.

There are some lengthy discussions on the Discord channel about this specific issue and it seems like there needs to be an option to either force HyperDHT to use a configurable interface when it is creating streams, or that it should use the same interface that the dht-rpc code is using under the hood for the DHT management. What it currently does is quite wrong.

[lanmower]

This looks very exciting, what are the caveats of making lan connections, do the lan computers make them offline as well?

Would there be cases that work offline like if one bootstraps to another?

[dipunm]

Hey all, I believe I am experiencing this same issue. I was unable to check out the dual-connect-lan branch, what is the status? Did it get abandoned or is there something I can do to help get it through?

[amunhoz]

Hi there, any news about it?

[mafintosh]

not yet, but this is close to being next on our list

[cshotton]

Did this ever get resolved? It doesn't seem to be an issue now, but I can't find a commit that actually fixed this. Did it just magically heal itself?