I'm trying to update packages from an ubuntu container; however, updating fails and I've noticed I can't connect anywhere, am able to lookup dns names thought.
I'm using nicolaka/netshoot container in order to test network.
I've used "tcpdump" command in order to trace any error related to messages being sent, and testing with ping from the container results in the following error "ICMP time exceeded in-transit".
tcpdump in host interface:
16:18:25.257270 IP 172.217.192.100 > nicolas: ICMP echo reply, id 33, seq 3, length 64
16:18:25.257314 IP nicolas > 172.217.192.100: ICMP time exceeded in-transit, length 92
16:18:26.237575 IP nicolas > 172.217.192.100: ICMP echo request, id 33, seq 4, length 64
16:18:26.286692 IP 172.217.192.100 > nicolas: ICMP echo reply, id 33, seq 4, length 64
16:18:26.286757 IP nicolas > 172.217.192.100: ICMP time exceeded in-transit, length 92
16:18:27.261770 IP nicolas > 172.217.192.100: ICMP echo request, id 33, seq 5, length 64
16:18:27.302193 IP 172.217.192.100 > nicolas: ICMP echo reply, id 33, seq 5, length 64
16:18:27.302241 IP nicolas > 172.217.192.100: ICMP time exceeded in-transit, length 92
16:18:28.285631 IP nicolas > 172.217.192.100: ICMP echo request, id 33, seq 6, length 64
16:18:28.329531 IP 172.217.192.100 > nicolas: ICMP echo reply, id 33, seq 6, length 64
16:18:28.329596 IP nicolas > 172.217.192.100: ICMP time exceeded in-transit, length 92
16:18:29.309767 IP nicolas > 172.217.192.100: ICMP echo request, id 33, seq 7, length 64
16:18:29.353202 IP 172.217.192.100 > nicolas: ICMP echo reply, id 33, seq 7, length 64
16:18:29.353272 IP nicolas > 172.217.192.100: ICMP time exceeded in-transit, length 92
Also I'm not sure if my iptables are as expected for docker containers to get internet connection.
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
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
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
Whats is your result of ping 8.8.8.8 in container?
or whats is your commend when you want to run container.
I'll close this question as I have found the problem is with my ISP, which by using double NAT (ISP NAT + Docker NAT) is blocking connections from my containers.
Related
when run a centos8 container on a centos7 host. in the container, add a iptables rule to one CHAIN(eg, filter table INPUT CHAIN), the rule will not only be added to INPUT CHAIN ,but also other CHAINs(eg OUTPUT,FORWARD, even PREROUTING,POSTROUTING)
run a centos8 container on a centos7 host
docker run -it --privileged centos:8 sh
when it running, install iptables in container
yum install -y iptables
show iptables version: iptables -V
iptables version: v1.8.4 (nf_tables)
list current rules: iptables -t nat -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
# Warning: iptables-legacy tables present, use iptables-legacy to see them
add a new rule: iptables -I INPUT -i eth0 -j REJECT
list rules again: iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 REJECT all -- eth0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
# Warning: iptables-legacy tables present, use iptables-legacy to see them
and I have test if run centos8 container on a centos8 host,this would not happen.
In one word: host and container mix iptables and nftables.
https://github.com/kubernetes/kubernetes/issues/71305
https://bugzilla.redhat.com/show_bug.cgi?id=1668007
I have a Docker Host that is connected to a non-default route network. My problem is now that I can't reach this Network from within the Docker Containers on the Docker Host.
Primary IP: 189.69.77.21 (default route)
Secondary IP: 192.168.77.21
Routing is like the following:
[root#mgmt]# route -n
Kernel IP Routentabelle
Ziel Router Genmask Flags Metric Ref Use Iface
0.0.0.0 189.69.77.1 0.0.0.0 UG 0 0 0 enp0s31f6
189.69.77.1 0.0.0.0 255.255.255.255 UH 0 0 0 enp0s31f6
172.17.0.0 0.0.0.0 255.255.0.0 U 0 0 0 docker0
192.168.77.0 0.0.0.0 255.255.255.0 U 0 0 0 enp0s31f6.4000
and IPtables untouched:
[root#mgmt]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy DROP)
target prot opt source destination
DOCKER-ISOLATION-STAGE-1 all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
DOCKER all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Chain DOCKER (1 references)
target prot opt source destination
ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:3000
Chain DOCKER-ISOLATION-STAGE-1 (1 references)
target prot opt source destination
DOCKER-ISOLATION-STAGE-2 all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
Chain DOCKER-ISOLATION-STAGE-2 (1 references)
target prot opt source destination
DROP all -- 0.0.0.0/0 0.0.0.0/0
RETURN all -- 0.0.0.0/0 0.0.0.0/0
I start the Docker Container with the following:
docker run -d --restart=unless-stopped -p 127.0.0.1:3000:3000/tcp --name mongoclient -e MONGOCLIENT_DEFAULT_CONNECTION_URL=mongodb://192.168.77.21:27017,192.168.77.40:27017,192.168.77.41:27017/graylog?replicaSet=ars0 -e ROOT_URL=http://192.168.77.21/nosqlclient mongoclient/mongoclient
I can reach the container (via NGINX Proxy) over Network but the container itself can only ping/reach the Docker Host IP and not others.
node#1c5cf0e8d14c:/opt/meteor/dist/bundle$ ping 192.168.77.21
PING 192.168.77.21 (192.168.77.21) 56(84) bytes of data.
64 bytes from 192.168.77.21: icmp_seq=1 ttl=64 time=0.078 ms
64 bytes from 192.168.77.21: icmp_seq=2 ttl=64 time=0.080 ms
64 bytes from 192.168.77.21: icmp_seq=3 ttl=64 time=0.079 ms
^C
--- 192.168.77.21 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 0.078/0.079/0.080/0.000 ms
node#1c5cf0e8d14c:/opt/meteor/dist/bundle$ ping 192.168.77.40
PING 192.168.77.40 (192.168.77.40) 56(84) bytes of data.
^C
--- 192.168.77.40 ping statistics ---
240 packets transmitted, 0 received, 100% packet loss, time 239000ms
So my question is, how can I make the Docker Container reach the hosts on the Network? My goal is to have a running mongoclient via Docker that can be used to manage the MongoDB ReplicaSet that is in that additional private Network.
You can use the network host in the container. So the container is use the host network and you can access the container and host network.
Here is the documentation:
https://docs.docker.com/network/host/
BR
Carlos
I installed a jenkins via Docker on my server and assigned to a specific domain (jenkins.mydomain.com), which works perfectly fine. But I can also reach jenkins (and every other service in docker) if I browse my domain with the service's port, for example: mydomain.com:8181
I'v already tried a few thing to block the port from the outside and make it only accessible via domain, but no luck.
First I tried to block the port for the eth0 interface:
iptables -A INPUT -i eth0 -p tcp --destination-port 8181 -j DROP
But it didn't work because when I tried to reach jenkins from the domain, I'v got an error 503.
Also tried to block the port for every incoming requests except docker's ip. It didn't work either.
So how can I make the ports unaccessible from the outside but accessible for Docker?
iptables -L -n --line-numbers
Chain INPUT (policy ACCEPT)
num target prot opt source destination
Chain FORWARD (policy ACCEPT)
num target prot opt source destination
1 DOCKER-ISOLATION all -- 0.0.0.0/0 0.0.0.0/0
2 DOCKER all -- 0.0.0.0/0 0.0.0.0/0
3 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED
4 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
5 ACCEPT all -- 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
num target prot opt source destination
Chain DOCKER (1 references)
num target prot opt source destination
1 ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:3000
2 ACCEPT tcp -- 0.0.0.0/0 172.17.0.2 tcp dpt:22
3 ACCEPT tcp -- 0.0.0.0/0 172.17.0.3 tcp dpt:8081
4 ACCEPT tcp -- 0.0.0.0/0 172.17.0.4 tcp dpt:50000
5 ACCEPT tcp -- 0.0.0.0/0 172.17.0.4 tcp dpt:8080
Chain DOCKER-ISOLATION (1 references)
num target prot opt source destination
1 RETURN all -- 0.0.0.0/0 0.0.0.0/0
i'm trying to install Docker on my Intel Edison that is running Ubilinux, but need some help.
i compiled the source code using this guide -> https://github.com/docker/docker/blob/master/project/PACKAGERS.md
... but when i try to run the daemon with "./docker daemon" i get this error:
xotl#ubilinux:~/docker/bundles/1.9.0-dev/binary$ sudo ./docker daemon
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
INFO[0000] [graphdriver] using prior storage driver "aufs"
INFO[0000] Option DefaultDriver: bridge
INFO[0000] Option DefaultNetwork: bridge
INFO[0000] Firewalld running: false
FATA[0001] Error starting daemon: Error initializing network controller: Error creating default "bridge" network: Failed to program NAT chain: Failed to inject docker in PREROUTING chain: iptables failed: iptables -t nat -A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER: iptables: No chain/target/match by that name.
(exit status 1)
xotl#ubilinux:~/docker/bundles/1.9.0-dev/binary$
Need help. =(
EDIT:
This is the output of the sudo iptables -L -v command:
xotl#ubilinux:~/docker/bundles/1.9.0-dev/binary$ sudo iptables -L -v
[sudo] password for xotl:
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all -- any docker0 anywhere anywhere ctstate RELATED,ESTABLISHED
0 0 ACCEPT all -- docker0 !docker0 anywhere anywhere
0 0 ACCEPT all -- docker0 docker0 anywhere anywhere
Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
xotl#ubilinux:~/docker/bundles/1.9.0-dev/binary$
This is the output of the sudo iptables -L -v -t natcommand:
xotl#El-Edison:~/docker/bundles/1.9.0-dev/binary$ sudo iptables -L -v -t nat
[sudo] password for xotl:
Chain PREROUTING (policy ACCEPT 4 packets, 1312 bytes)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 4 packets, 1312 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 65 packets, 4940 bytes)
pkts bytes target prot opt in out source destination
Chain POSTROUTING (policy ACCEPT 65 packets, 4940 bytes)
pkts bytes target prot opt in out source destination
0 0 MASQUERADE all -- any !wlan0 10.10.0.0/21 anywhere
Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination
Docker requires a 64-bit version of your Operating system (https://docs.docker.com/engine/installation/ubuntulinux/). The Intel Edison runs a 32-bit processor and will not be able to run Docker (at least, that's what I found after spending some time researching this.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 7 years ago.
Improve this question
I have a virtual interface (oip1) configured which has a valid IP config. When I try to ping an address on the internet from oip1, I can see the ICMP echo requests/replies on tcpdump, but ping still reports 100% failing.
root#openair-PC:~/openair4G# ifconfig oip1
oip1 Link encap:AMPR NET/ROM HWaddr
inet addr:192.188.0.2 Bcast:192.188.0.255 Mask:255.255.255.0
UP BROADCAST RUNNING NOARP MULTICAST MTU:1500 Metric:1
RX packets:10 errors:0 dropped:0 overruns:0 frame:0
TX packets:10 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:840 (840.0 B) TX bytes:840 (840.0 B)
I've created a new table "lte":
root#openair-PC:~/openair4G# ip rule show
0: from all lookup local
32743: from all fwmark 0x1 lookup lte
32766: from all lookup main
32767: from all lookup default
Thus, I'm marking packets to/from oip1 address:
root#openair-PC:~/openair4G# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
MARK all -- anywhere 192.188.0.0/24 MARK set 0x1
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
MARK all -- 192.188.0.0/24 anywhere MARK set 0x1
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
Then, I added a default gateway for table "lte":
root#openair-PC:~/openair4G# ip route show table lte
default dev oip1 scope link
ping result:
openair#openair-PC:~/openair4G/cmake_targets$ ping -c 5 -I oip1 8.8.8.8
PING 8.8.8.8 (8.8.8.8) from 192.188.0.2 oip1: 56(84) bytes of data.
^C
--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 received, 100% packet loss, time 3999ms
tcpdump screen:
openair#openair-PC:~/openair4G$ sudo tcpdump -p -i oip1
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on oip1, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes
17:19:10.576680 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 1, length 64
17:19:11.021851 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 1, length 64
17:19:11.576617 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 2, length 64
17:19:11.752243 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 2, length 64
17:19:12.576583 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 3, length 64
17:19:12.676980 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 3, length 64
17:19:13.576559 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 4, length 64
17:19:13.767922 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 4, length 64
17:19:14.576561 IP 192.188.0.2 > google-public-dns-a.google.com: ICMP echo request, id 20987, seq 5, length 64
17:19:15.097164 IP google-public-dns-a.google.com > 192.188.0.2: ICMP echo reply, id 20987, seq 5, length 64
^C
10 packets captured
10 packets received by filter
0 packets dropped by kernel
As you can see, all packets can be seen by tcpdump.
Does anyone have an idea about this ?
Best regards,
I finally solved this. It was cause by rp_filter activated on the concerned interface and on all the system as well. I disabled it with: sysctl -w net.ipv4.conf.all.rp_filter=0 (replace all with the interface also).
This could have been caused by the reverse-path-filtering done by kernel. This is likely to occur if you are doing things like proxy-arp in the next hop. The system thinks that the packet received is a spoofed one (if the reverse-path-filtering is enabled) and drops it.
Obvious (but not suggested) way is to disable the reverse-path-filtering. Another way is to set the default gateway in the host for the pinged IP, through the intended interface.