amacneil/docker-bitcoin

Docker's bridge network shows issue with bitcoind's peer ban

roshii opened this issue · 5 comments

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

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

see a forked code I played around with

I have the same issue, for all the ports.

2017-12-30 18:51:20 connection from 172.17.0.1:50006 dropped (banned)
2017-12-30 18:51:20 connection from 172.17.0.1:50008 dropped (banned)
2017-12-30 18:51:20 connection from 172.17.0.1:50010 dropped (banned)
2017-12-30 18:51:20 connection from 172.17.0.1:50012 dropped (banned)
2017-12-30 18:51:20 connection from 172.17.0.1:50014 dropped (banned)
ETC...

RPC from the cli works fine.

Did you find a solution?

I do run the docker image with Host network, which solves the above