Cannot access network from Docker container - linux

The gist of the issue is that if I create and run a docker container (from any image, I tried many) the container does not have network access beyond the default bridge Docker creates; even when using IP addresses (not URLs/names).
I.e.
docker run --rm -it busybox ping 8.8.8.8 hangs/fails for not having accessing the network
docker run --rm -it busybox ping 172.17.0.1 also fails (note that 172.17.0.1 is docker0's IP on the host and also the gateway set by docker in the container)
if I create two containers I can ping either one from the other fine
N.B:
I have two Ubuntu hosts (same version) both running Docker 19.03.6. On one of them (dev machine) I don't have the issue (it works just fine), on the other one I do. Which means it is most likely not an OS and/or Docker version issue but some sort of misconfiguration.
It is not the DNS issue asked in most questions I could find. In fact, it is not a DNS issue at all. It presents itself when I use direct IP addresses as well as with URLs.
I use iptables on the host; these are the rules on the one where it does not work (they are different on the dev machine where networking works fine but I cannot set the here the same):
Chain INPUT (policy DROP)
target prot opt source destination
f2b-postfix-sasl tcp -- anywhere anywhere multiport dports smtp,urd,submission,imap3,imaps,pop3,pop3s
f2b-sshd tcp -- anywhere anywhere multiport dports ssh
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
fail2ban-ssh tcp -- anywhere anywhere multiport dports ssh
ACCEPT all -- anywhere anywhere
ACCEPT all -- anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere tcp dpt:https
ACCEPT icmp -- anywhere anywhere icmp echo-request
ACCEPT udp -- anywhere anywhere udp spt:ntp state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:imap2 state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:imaps state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:submission state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp state NEW,ESTABLISHED
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
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT udp -- anywhere anywhere udp dpt:ntp state NEW,ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:imap2 state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:imaps state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp dpt:urd state ESTABLISHED
ACCEPT tcp -- anywhere anywhere tcp spt:smtp state ESTABLISHED
Chain DOCKER (1 references)
target prot opt source destination
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-postfix-sasl (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain f2b-sshd (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
Chain fail2ban-ssh (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
RETURN all -- anywhere anywhere
I am not sure what else to add for clarification.
What should I do?

Related

Docker listening inside the docker host for RabbitMQ but not from outside, why?

This is how I run the rabbitMQ image:
docker run -d --restart always --hostname host-rabbit --name cg-rabbit -p 5029:5672 -p 5020:15672 -e RABBITMQ_DEFAULT_VHOST=sample_vhost -e RABBITMQ_DEFAULT_USER=sampleuser -e RABBITMQ_DEFAULT_PASS=samplepass rabbitmq:3-management
Now in netstat -nltp:
ubuntu#infra:~$ netstat -nltp
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 127.0.0.53:53 0.0.0.0:* LISTEN -
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN -
tcp6 0 0 :::22 :::* LISTEN -
tcp6 0 0 :::5020 :::* LISTEN -
tcp6 0 0 :::5029 :::* LISTEN -
I'm not sure why I see tcp6 when docker exposes ports to host and if it makes issues!
Now when I telnet from within the server I can see that port is open:
ubuntu#infra:~$ telnet MY-SERVER-IP-ADDRESS 5029
Trying MY-SERVER-IP-ADDRESS...
Connected to MY-SERVER-IP-ADDRESS.
Escape character is '^]'.
^]
telnet> Connection closed.
But in my machine when I try to telnet (or from another server):
$ telnet MY-SERVER-IP-ADDRESS 5020
Trying MY-SERVER-IP-ADDRESS...
^C
iptables -L reports:
sudo iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5020
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:5029
ACCEPT tcp -- anywhere anywhere
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
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:amqp
ACCEPT tcp -- anywhere 172.17.0.2 tcp dpt:15672
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- anywhere anywhere
RETURN all -- anywhere anywhere
Chain DOCKER-USER (1 references)
target prot opt source destination
RETURN all -- anywhere anywhere
It is good to note that I have installed a redis server in server (non-docker) and I am able to telnet to it form outside.
EDIT-1:
sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere !localhost/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:15672
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:amqp
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
DNAT tcp -- anywhere anywhere tcp dpt:15672 to:172.17.0.2:15672
DNAT tcp -- anywhere anywhere tcp dpt:amqp to:172.17.0.2:5672
EDIT-2:
Docker configuration:
ubuntu#infra:~$ sudo cat /var/snap/docker/796/config/daemon.json
{
"log-level": "error",
"storage-driver": "overlay2"
}
This is really odd. By flushing the NAT in iptables everything works as expected:
iptables -t nat -F
My nat before flushing:
ubuntu#infra:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere !localhost/8 ADDRTYPE match dst-type LOCAL
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.17.0.0/16 anywhere
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:15672
MASQUERADE tcp -- 172.17.0.2 172.17.0.2 tcp dpt:amqp
Chain DOCKER (2 references)
target prot opt source destination
RETURN all -- anywhere anywhere
DNAT tcp -- anywhere anywhere tcp dpt:15672 to:172.17.0.2:15672
DNAT tcp -- anywhere anywhere tcp dpt:amqp to:172.17.0.2:5672
And now after flushing everything is gone:
ubuntu#infra:~$ sudo iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Chain DOCKER (0 references)
target prot opt source destination
NOTE: by restarting docker via sudo snap restart docker net rules are back again and I had to flush NATs again!

Centos 6.4 Nodejs external not responding

I am new to ssh and Centos 6.4 and I want to run nodejs on port 80. But couldn't make it to work external.
When I type netstat -anp | grep 8080 I can see that my node listening.
tcp 0 0 0.0.0.0:8080 0.0.0.0:* LISTEN 7976/node
But it is not going external.
I tried to add settings to iptables and result is same again. It is not working.
[root#culturalinfluences ~]# iptables --list
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT icmp -- anywhere anywhere
ACCEPT all -- anywhere anywhere
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http /* node.js port */
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:webcache /* node.js port */
Chain FORWARD (policy ACCEPT)
target prot opt source destination
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Here is my nodejs
var port = 8080;
app.listen(port, "0.0.0.0" ,function() {
console.log("Listening on " + port);
});
Thank you four understand cause I am really new into linux and its iptables system. I am sure people like me will search the same issue and I hope they will find answer from this question.
Thank you for your helps.
You have a
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
right before the "http" ports you're allowing, so those rules will never be reached. Move the REJECT all rule to the bottom of the list instead.
Additionally you may want to use -n on the iptables command line to make sure the port numbers are right and aren't 80 instead of 8080 for example.

Can't connect to Apache Server Remotely

I set apache in puppy linux and can see files in localhost.However,when I opened port80 and tried to connect apache from iphone but it failed. I could see just a white page.Maybe it wassn't 404 because it didn't show 404 error.(before I opened the port, i saw 404.)
I have configured apache.conf to Allow from all.
The access log and error logs showed nothing.
this is iptables-L
Chain INPUT (policy DROP)
target prot opt source destination
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ftp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:smtp
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:domain
ACCEPT udp -- anywhere anywhere state NEW udp dpt:domain
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:finger
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:www
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:pop3
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:auth
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:imap2
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:443
ACCEPT udp -- anywhere anywhere state NEW udp dpt:syslog
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:printer
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:993
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:995
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:www
ACCEPT udp -- anywhere anywhere state NEW udp dpt:www
A CCEPT all -- anywhere anywhere state NEW
TRUSTED all -- anywhere anywhere state NEW
Chain FORWARD (policy DROP)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
DROP icmp -- anywhere anywhere state INVALID
Chain TRUSTED (1 references)
target prot opt source destination
ACCEPT icmp -- anywhere anywhere icmp echo-request
DROP icmp -- anywhere anywhere
REJECT all -- anywhere anywhere reject-with icmp-port- unreachable
Netstat
tcp 0 0 192.168.100.100:80 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN
How do i solve this problem?
tcp 0 0 192.168.100.100:80
The problem is right here. The server is listening at a specific, local, IP address, rather than 0.0.0.0.

can't open PORT on IPTABLES firewall

I'm struggling to understand why I can't open port 61616 by adding IPTABLES rule. Here is the listing of all rules, obtained via IPTABLES -L command.
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:61616
ACCEPT udp -- anywhere anywhere udp dpt:cslistener
ACCEPT tcp -- anywhere anywhere tcp dpt:cslistener
ACCEPT tcp -- anywhere anywhere tcp dpt:webcache
ACCEPT tcp -- anywhere anywhere tcp dpt:smtp
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT tcp -- anywhere anywhere tcp dpt:61616
ACCEPT tcp -- anywhere anywhere tcp dpt:http
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
As much as I'm ignorant about IPTABLES, what confuses me is that http port is visible from the outside, yet port 61616 still isn't. For me, the rules look the same. Anyways, all help's appreciated.
Best
Maybe you try to open port for host in the network behind the CentOS host (CentOS host is firewall for network)?
If so, you must add rule for chain FORWARD of table filter, and you should
add rule for DNAT to some IP in network x.x.x.x
iptables -A FORWARD -p tcp --dport 61616 -j ACCEPT
iptables -A PREROUTING -t nat -p tcp --dport 61616 -j DNAT --to-destinanion x.x.x.x

Why doesn't my iptables entries block pinging a Xen virtual machine? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I'm writing a bash script to add simple firewalling for Xen.
Here's the actual firewall configuration :
Chain INPUT (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
RH-Firewall-1-INPUT all -- anywhere anywhere
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain RH-Firewall-1-INPUT (2 references)
target prot opt source destination
ACCEPT all -- anywhere anywhere
ACCEPT icmp -- anywhere anywhere icmp any
ACCEPT esp -- anywhere anywhere
ACCEPT ah -- anywhere anywhere
ACCEPT udp -- anywhere 224.0.0.251 udp dpt:mdns
ACCEPT udp -- anywhere anywhere udp dpt:ipp
ACCEPT tcp -- anywhere anywhere tcp dpt:ipp
ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED
ACCEPT udp -- anywhere anywhere state NEW udp dpt:ha-cluster
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:ssh
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:http
ACCEPT tcp -- anywhere anywhere state NEW tcp dpt:https
REJECT all -- anywhere anywhere reject-with icmp-host-prohibited
I'd like to add a new chain for each of my virtual machines (each of them has a virtual interface called vif1.0, vif2.0, etc). Output interface (bridge) is xenbr0.
Here's what I do (for example to block ping 'in'to domU1, vif1.0) :
iptables -N domUFirewall
iptables -I FORWARD -j domUFirewall
iptables -I INPUT -j domUFirewall
iptables -A domUFirewall -i vif1.0 -p icmp -j DROP
But .. it doesn't work, i'm still able to ping in/out the domU.
Must be something really 'dumb' but I can't find out what's wrong.
Any clues ?
Thx
Since you're using XEN with bridged networking, packets are being intercepted at a level before ordinary iptables commands can influence them. Thus, you'll probably need to use the ebtables command to influence packet routing in the way that you want to.
ebtables/iptables interaction on a Linux-based bridge
ebtables(8) - Linux man page
Xen Wiki * XenNetworking
Original answer left below that will work for other configurations, but not for XEN with bridged networking.
I am going to pretend for the sake of example that the IP address of vif1.0 is 192.168.1.100.
I would redo the logic to not check the input device, but to instead check by IP Address. At the input chain, the packet is coming from (say) device eth0, not from vif1.0. Thus, this rule:
iptables -I INPUT -i vif1.0 -j domUFirewall
that I previously proposed will never match any packets. However, if you do the following, it should do what you want:
iptables -I INPUT -d 192.168.1.100 -j domUFirewall
where in this case the chain domUFirewall is set up by:
iptables -N domUFirewall
iptables -F domUFirewall
iptables -A domUFirewall -p icmp -j DROP
If a given chain is for a single device, then you want to make this check before jumping into the chain, on a rule with the "-j chainName" action. Then, in the chain itself, you never have to check for the device or IP Address.
Second, I would always flush (empty) the chain in your script, just in case you're re-running the script. Note that when you rerun the script, you may get complaints on the -N line. That's OK.
There are other ways you could do this, but to give a different example, I would need to know specifically how your VM is set up -- bridged networking? NAT? Etc. But the example I gave here should work in any of these modes.
Here are some useful links for the future:
Quick HOWTO, Ch14: Linux Firewalls Using iptables
Sandbox a VMware Virtual Machine With iptables

Resources