Docker containers don't have Internet access with Eduroam

danholee · 2019-10-25 11:10:29

Hello,

My containers do not have Internet access when I'm connected to a university network (Eduroam), only accessing the host is possible.

More precisely, when I'm connected with my home connection or with my smartphone one, the containers can access the Internet. I don't think this is about university-firewall or something, because I can run containers on Windows and other Linux with the same network.

A simple example for understanding, through an alpine container (host$ docker run -it --rm alpine ash):

/ # cat /etc/resolv.conf 
# Generated by resolvconf
domain univ-[CENSORED]
nameserver 10.9.0.10
nameserver 10.200.9.10

/ # ping -c2 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes

--- 8.8.8.8 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

/ # ping -c2 10.9.0.10
PING 10.9.0.10 (10.9.0.10): 56 data bytes

--- 10.9.0.10 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

/ # ip addr show eth0
       valid_lft forever preferred_lft forever
53: eth0@if54: <BROADCAST,MULTICAST,UP,LOWER_UP,M-DOWN> mtu 1500 qdisc noqueue state UP 
    link/ether 02:42:ac:11:00:04 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.4/16 brd 172.17.255.255 scope global eth0
       valid_lft forever preferred_lft forever

/ # ping -c2 172.17.0.1
PING 172.17.0.1 (172.17.0.1): 56 data bytes
64 bytes from 172.17.0.1: seq=0 ttl=64 time=0.210 ms
64 bytes from 172.17.0.1: seq=1 ttl=64 time=0.164 ms

--- 172.17.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.164/0.187/0.210 ms

The resolv.conf is exactly the same as the one the host, which comes from DHCP Eduroam Server.

I don't clearly understand, I read the Wiki's Docker page but sysctl net.ipv4.ip_forward is 1 as suggested (in host and containers), and I'm not using something else for replacing iptables. I also don't use systemd-network, I use NetworkManager (and usa KDE Plasma as DE: KDE Plasma controls it).

On host I do have these configuration (completely automated) with one Docker container running (in this case gitlab/gitlab-runner):

@host $ ip route
default via 10.39.0.1 dev wlp2s0 proto dhcp src 10.39.251.25 metric 303 
10.39.0.0/16 dev wlp2s0 proto dhcp scope link src 10.39.251.25 metric 303 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1

@host $ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: enp1s0f1: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000
    link/ether CENSORED brd ff:ff:ff:ff:ff:ff
3: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    link/ether CENSORED brd ff:ff:ff:ff:ff:ff
    inet 10.39.250.72/16 brd 10.39.255.255 scope global dynamic noprefixroute wlp2s0
       valid_lft 27990sec preferred_lft 27990sec
    inet 10.39.251.25/16 brd 10.39.255.255 scope global secondary dynamic noprefixroute wlp2s0
       valid_lft 28182sec preferred_lft 24582sec
    inet6 fe80::CENSOREDcc/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
    inet6 fe80::CENSOREDc4/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default 
    link/ether 02:42:d9:01:31:dc brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
       valid_lft forever preferred_lft forever
    inet6 fe80::8adf:cfa9:22b4:34bc/64 scope link 
       valid_lft forever preferred_lft forever
8: veth7cdb731@if7: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP group default 
    link/ether 6a:8f:bd:b5:4d:7d brd ff:ff:ff:ff:ff:ff link-netnsid 0
    inet6 fe80::6390:cd60:4d83:4acb/64 scope link 
       valid_lft forever preferred_lft forever

And this is what looks like my iptables (no personal edit either):

@host # 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

As I'm able to access the Internet with my smartphone AP/Ethernet USB or my home connection, I suppose there is something to do with routing packets.

Do you have any idea of what I could have done wrong, or any idea for further debugging?

Arch Linux

#1 2019-10-25 11:10:29

Docker containers don't have Internet access with Eduroam

Board footer