-
Notifications
You must be signed in to change notification settings - Fork 76
Docker's bridge network shows issue with bitcoind's peer ban #32
Comments
Interesting. This doesn't seem right, since the docker bridge network should be no different than any other NAT environment. Are you exposing 8333 externally? |
Yes 8333 is exposed, external peers - from the wild wild web - which are causing the ban as well as internal peers - within my lan - end up being banned . I guess docker's peers would work since they'd have an 172.17.x.y IP and not 172.17.0.1 but that make sense to me since we have to allow 172.16.0.0/twenty something for RPC connection |
I've noticed some dev were using socat to allow rpc connections and I'm not sure what it does exactly under the hood. maybe something to dig out |
I have the same issue, for all the ports. 2017-12-30 18:51:20 connection from 172.17.0.1:50006 dropped (banned) RPC from the cli works fine. Did you find a solution? |
I do run the docker image with Host network, which solves the above |
Running bitcoind in a docker bridge network can have unintended consequence. As a matter of fact, I've been running the later which became unreachable to peers in less than 24h while RPC connections were working fine. After verifying data was reaching bitcoind thru port 8333, I realize bitcoind had banned peer 172.17.0.1 - docker bridge interface - due to its misbehavior. I manually removed banlist.dat from data, restarted the docker image, and had the very same error within 20h.
As far as I understand docker bridge network and bitcoin peering mechanism seem to be incompatible since there seem to be no way at identifying peers (all being 172.17.0.1:xxxxx). Unless setting up a sock5 or tor proxy within the image?
As far as I'm concerned, I'm now running it with docker host network, not sure if there would be other options
The text was updated successfully, but these errors were encountered: