3

The situation is, for a simple docker command:

docker run -d -p 3128:3128 my_squid_container

it works fine within my home. However, when using the same Docker container in the Azure Ubuntu server, I get:

$ curl --proxy http://localhost:3128 http://google.com
curl: (56) Recv failure: Connection reset by peer

After a heck of troubleshooting, it turns out that the Docker default network (of the the Azure Ubuntu server) is blocked, by some kind of firewall I suppose, but I couldn't figure out / confirm the real source.

There has been suspicious of UFW, but I saw:

Moreover, my UFW status is inactive:

$ sudo ufw status
Status: inactive

So is it true that UFW is blocking my Docker network connection?

Trying to answer it myself, I checked How do I know if my firewall is on?, and here is the relevant information that might help:

$ sudo ufw status
Status: inactive

$ sudo iptables -v -x -n -L
Chain INPUT (policy ACCEPT 186 packets, 67614 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
    pkts      bytes target     prot opt in     out     source               destination
   83321 462267984 DOCKER-USER  all  --  *      *       0.0.0.0/0            0.0.0.0/0
   83321 462267984 DOCKER-ISOLATION-STAGE-1  all  --  *      *       0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
       0        0 DOCKER     all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
       0        0 ACCEPT     all  --  docker0 docker0  0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 244 packets, 55542 bytes)
    pkts      bytes target     prot opt in     out     source               destination

Chain DOCKER (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 ACCEPT     tcp  --  !docker0 docker0  0.0.0.0/0            172.17.0.2           tcp dpt:3128

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DOCKER-ISOLATION-STAGE-2  all  --  docker0 !docker0  0.0.0.0/0            0.0.0.0/0
   83729 466271977 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-ISOLATION-STAGE-2 (1 references)
    pkts      bytes target     prot opt in     out     source               destination
       0        0 DROP       all  --  *      docker0  0.0.0.0/0            0.0.0.0/0
   44567 231463994 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0

Chain DOCKER-USER (1 references)
    pkts      bytes target     prot opt in     out     source               destination
  245275 2311152470 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0


# NAT setting

$ sudo iptables -t nat -v -x -n -L
Chain PREROUTING (policy ACCEPT 60056 packets, 2443714 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
   80820  3320327 DOCKER     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ADDRTYPE match dst-type LOCAL

Chain INPUT (policy ACCEPT 60053 packets, 2443525 bytes)
    pkts      bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 217217 packets, 13050882 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 DOCKER     all  --  *      *       0.0.0.0/0           !127.0.0.0/8          ADDRTYPE match dst-type LOCAL

Chain POSTROUTING (policy ACCEPT 217217 packets, 13050882 bytes)
    pkts      bytes target     prot opt in     out     source               destination         
       3      189 MASQUERADE  all  --  *      !docker0  172.17.0.0/16        0.0.0.0/0           
       0        0 MASQUERADE  tcp  --  *      *       172.17.0.2           172.17.0.2           tcp dpt:3128

Chain DOCKER (2 references)
    pkts      bytes target     prot opt in     out     source               destination         
       0        0 RETURN     all  --  docker0 *       0.0.0.0/0            0.0.0.0/0           
       0        0 DNAT       tcp  --  !docker0 *       0.0.0.0/0            0.0.0.0/0            tcp dpt:3128 to:172.17.0.2:3128

I do have fail2ban installed and running BTW, but I doubt that it is blocking my internal port usage.

All in all, who is blocking my docker default network? Thx.

UPDATE2:

The docker default network was blocked initially, but suddenly it worked for no reason, as explained below, but now docker network is blocked again. Good that I've listed the output of the iptable, including the NAT setting, so I can do a comparison of then and now. And it turns out that for the above two iptable commands, their rules are still the same -- the output only differ with packets & bytes numbers.

so UFW should be ruled out from the cause. If confirmed I'll remove its tag.

UPDATE: (it suddenly worked for no reason for a very short while)

I don't know what happened, but I was about to give more info, and this is what I get, word for word, nothing more nothing less:

$ curl --proxy http://localhost:3128 https://google.com
curl: (56) Proxy CONNECT aborted

$ curl -v --proxy http://localhost:3128 http://google.com
* Rebuilt URL to: http://google.com/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3128 (#0)
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.58.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 301 Moved Permanently
< Location: http://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Sat, 10 Aug 2019 18:06:51 GMT
< Expires: Mon, 09 Sep 2019 18:06:51 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 219
< X-XSS-Protection: 0
< X-Frame-Options: SAMEORIGIN
< X-Cache: MISS from 5c83ae696b4c
< X-Cache-Lookup: MISS from 5c83ae696b4c:3128
< Via: 1.1 5c83ae696b4c (squid/4.8)
< Connection: keep-alive
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="http://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host localhost left intact

$ curl --proxy http://localhost:3128 https://google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>

Honestly, I don't know what's going on, and you can see that it didn't work before, even today, and it is suddenly working right before my eyes.

So let me include back what I posted in OP (although no further details than that), and what happened before:

$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-USER  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-1  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (2 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.19.0.2           tcp dpt:3128

Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target     prot opt source               destination
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
DOCKER-ISOLATION-STAGE-2  all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-ISOLATION-STAGE-2 (2 references)
target     prot opt source               destination
DROP       all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere
RETURN     all  --  anywhere             anywhere

Chain DOCKER-USER (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

$ curl -v --proxy http://localhost:3128 http://google.com
* Rebuilt URL to: http://google.com/
*   Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 3128 (#0)
> GET http://google.com/ HTTP/1.1
> Host: google.com
> User-Agent: curl/7.58.0
> Accept: */*
> Proxy-Connection: Keep-Alive
>
* Recv failure: Connection reset by peer
* stopped the pause stream!
* Closing connection 0
curl: (56) Recv failure: Connection reset by peer
xpt
  • 1,045
  • It is likely your "DOCKER-ISOLATION-STAGE-2" chain, however we can not actually tell from your listing. sudo iptables -L doesn't give us all the information needed. Please edit your question and replace it with the output from sudo iptables -v -x -n -L. – Doug Smythies Aug 09 '19 at 15:13
  • Oh, thanks a lot for your reply and I'm more than happy to make the change @DougSmythies, as this is my first hope to see the light for my total darkness tunnel. OP updated. thx. – xpt Aug 10 '19 at 18:05
  • It does not appear to be "DOCKER-ISOLATION-STAGE-2". Actually, there aren't any DROPped packets anywhere. Perhaps somewhere in the NAT chain, look with sudo iptables -t nat -v -x -n -L. – Doug Smythies Aug 11 '19 at 15:50
  • Hi @DougSmythies, my docker network is blocked again. I've compared the above two iptable commands, but their rules are still the same. See updated OP. So can we rule out iptable rules being the cause? thx – xpt Aug 13 '19 at 16:16
  • yes, I think so, iptables is not the cause. – Doug Smythies Aug 13 '19 at 18:47

0 Answers0