5

I have an IPv6 native container running a small webapp on port 8000.

On the Docker host, I can access the webservice using the global IP, but get 'connection refused' when connecting from another host. However, the container can be pinged from the other host.

The service in the container works

# curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000"
I'm b6032b33bc12

However, running from another host:

{2.1.5p273} curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000"
curl: (7) Failed to connect to 2a01:4f8:10a:2cc5:0:242:ac11:2 port 8000: Connection refused

Yet, the ipv6 address is pingable:

{2.1.5p273} ping6 2a01:4f8:10a:2cc5:0:242:ac11:2
PING 2a01:4f8:10a:2cc5:0:242:ac11:2(2a01:4f8:10a:2cc5:0:242:ac11:2) 56 data bytes
64 bytes from 2a01:4f8:10a:2cc5:0:242:ac11:2: icmp_seq=1 ttl=60 time=0.385 ms
64 bytes from 2a01:4f8:10a:2cc5:0:242:ac11:2: icmp_seq=2 ttl=60 time=0.452 ms

What have I missed?

Some more details about my environment:

# docker -
Docker version 17.03.1-ce, build c6d412e

The daemon uses the following args to enable ipv6:

--experimental=true --ipv6 --fixed-cidr-v6=2a01:4f8:10a:2cc5::2/64

The host has a routed ipv6 /64 subnet, which is has one ip allocated to eth0, and the remaining subnet on docker0.

# ifconfig
docker0   Link encap:Ethernet  HWaddr 02:42:c8:f8:5c:7b
      inet addr:172.17.0.1  Bcast:0.0.0.0  Mask:255.255.0.0
      inet6 addr: fe80::1/64 Scope:Link
      inet6 addr: fe80::42:c8ff:fef8:5c7b/64 Scope:Link
      inet6 addr: 2a01:4f8:10a:2cc5::1/64 Scope:Global
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:129 errors:0 dropped:0 overruns:0 frame:0
      TX packets:121 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:0
      RX bytes:9536 (9.3 KiB)  TX bytes:11130 (10.8 KiB)

eth0      Link encap:Ethernet  HWaddr 90:1b:0e:c4:3d:a1
      inet addr:88.99.148.135  Bcast:88.99.148.191  Mask:255.255.255.192
      inet6 addr: fe80::921b:eff:fec4:3da1/64 Scope:Link
      inet6 addr: 2a01:4f8:10a:2cc5::2/128 Scope:Global
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:107917 errors:0 dropped:0 overruns:0 frame:0
      TX packets:25223 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000
      RX bytes:143498170 (136.8 MiB)  TX bytes:2953043 (2.8 MiB)
      Interrupt:16 Memory:f7000000-f7020000

The container has a global ipv6

docker exec b6032b33bc12 ifconfig eth0
eth0      Link encap:Ethernet  HWaddr 02:42:ac:11:00:02
      inet addr:172.17.0.2  Bcast:0.0.0.0  Mask:255.255.0.0
      inet6 addr: fe80::42:acff:fe11:2/64 Scope:Link
      inet6 addr: 2a01:4f8:10a:2cc5:0:242:ac11:2/64 Scope:Global

Routing for ipv6 is in place, and appears to work:

# ip -6 route
2a01:4f8:10a:2cc5::2 dev eth0  proto kernel  metric 256
2a01:4f8:10a:2cc5::/64 dev docker0  proto kernel  metric 256
2a01:4f8:10a:2cc5::/64 dev docker0  metric 1024
fe80::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev docker0  proto kernel  metric 256
fe80::/64 dev veth0fbfa39  proto kernel  metric 256
default via fe80::1 dev eth0  metric 1024

The host has outbound connectivity:

# ping6 google.com
PING google.com(fra16s20-in-x0e.1e100.net) 56 data bytes
64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=1 ttl=56 time=5.08 ms

As does the container

# docker exec b6032b33bc12 ping6 google.com
PING google.com(fra16s20-in-x0e.1e100.net) 56 data bytes
64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=1 ttl=55 time=5.00 ms
64 bytes from fra16s20-in-x0e.1e100.net: icmp_seq=2 ttl=55 time=5.00 ms

I suspect there's an iptables issue:

# iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
Chain FORWARD (policy DROP)
target     prot opt source               destination
DOCKER-ISOLATION  all  --  anywhere             anywhere
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate     RELATED,ESTABLISHED
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:8000
Chain DOCKER-ISOLATION (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

And the ipv6 equivalent:

# ip6tables -L
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

1 Answer 1

1

Looking through your entire configuration I don't see anything wrong in it.

Everything I have used from Hetzner came with only a link prefix and no routed prefix. But I tried mtr from a machine outside of Hetzner's network, and the output looks like 2a01:4f8:10a:2cc5::/64 really is a routed prefix.

Assigning a single address from your routed prefix on your eth0 is a bit unusual. But since you did assign it as a /128 that is still a valid configuration. And if your server came with only a routed prefix and no link prefix, then assigning a /128 in that way is a sensible configuration.

Since I couldn't find any problems in your configuration, I instead tried to reproduced the problem from my machine, and I couldn't.

$ curl "http://[2a01:4f8:10a:2cc5:0:242:ac11:2]:8000"
I'm b6032b33bc12

That leads me to the conclusion that the problem likely lies on the machine where you ran that curl command (or on the network it is attached to).

Since you didn't tell us anything about that machine, I cannot say more specifically what the problem is. What you can try is to compare the output of these two commands:

traceroute 2a01:4f8:10a:2cc5:0:242:ac11:2
traceroute -p 8000 2a01:4f8:10a:2cc5:0:242:ac11:2

Here I am using the traceroute package on Ubuntu 16.04. Other traceroute versions may need different arguments.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .