That's typically because iptables on the host is blocking access from the docker networks. You can look at iptables -S or iptables -nvL to see your current rules.
That said, if you do open up the docker API, you need to be careful about who can access that API. Using port 2375 typically means you have not configured mTLS, see docker's guide for setting up mTLS. This means anyone with access to the port can submit API calls, which means an unprivileged local user, or any other container, has the ability to get root on your host. In your case, that's as easy as:
The recommended solution is to either use DinD to run the docker engine inside of a container, or to share the docker socket as a file/volume mount with the appropriate UID/GID access to the file. That ensures only that container has access to the docker engine rather than all users and any container running on the host. To handle the UID/GID access issues with files mounted in a volume, I've done this specifically for Jenkins images in my jenkins-docker repo, and there's a more generic solution in my fix-perms script in my docker-base repo.
@BMitch - I've figure it out - but your got it right as well (should you post it as an answer I'll accept and delete mine)
the iptables blocked the access.
once I opened it - it worked as expected.
Additionally, exposing the docker socket to the network makes it trivial to hack the server. Anyone with network access, whether an unprivileged local user or anyone remote, can run docker -H tcp://172.17.0.1:2375 run -it --rm --privileged --pid host debian nsenter -t 1 -m -u -n -i bash to get root. Either give access to the socket file with group permissions and a volume mount, or setup mTLS. Redirecting…