robbertkl / docker-ipv6nat

Extend Docker with IPv6 NAT, similar to IPv4

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Cannot resolve host error inside container

amjd opened this issue · comments

Hi,

I am not able to get IPv6 to work inside a container with docker-ipv6nat. The host machine has IPv6 support, and even the containers seem to support IPv6 when run with --net=host. This is what I did:

I created a user-defined network according to the README file as below:

sudo docker network create --ipv6 --subnet=fd00:dead:beef::/48 ipv6net

Then I started the docker-ipv6nat container:

sudo docker run -d --restart=always -v /var/run/docker.sock:/var/run/docker.sock:ro --privileged --net=host robbertkl/ipv6nat

Then I ran my own container:

sudo docker run --net=ipv6net -it ipv6 bash

Within this container, when I ping6 or curl -6 an IPv6-supporting site, I get the following errors:

root@e81edd040b76:/# curl -6 google.com
curl: (6) Could not resolve host: google.com
root@e81edd040b76:/# ping6 google.com
unknown host

Apparently, ping and curl are failing to resolve URLs too. It looks like something is going wrong with the container's DNS when using this particular combination of user-defined network and docker-ipv6nat. Please help if you have any insight about this.

Can you check a couple of things:

  • Do you see any error messages in the log output of your ipv6nat container?

  • Run ip6tables-save to output the IPv6 rules and see if ipv6nat has created the necessary rules.

  • Try pinging an IPv6 address directly, instead of a hostname, so that we can be sure if the problem is DNS only, or IPv6 connectivity in general. For example:

ping6 2001:4860:4860::8888

I have the same problem. Even better I can't ping6 from the host anymore after starting the first container with --net=ipv6net. Same when I use the default Docker bridge with IPv6. It works again when I stop the docker-ipv6nat container.

  • No log messages from the ipv6nat container
  • ip6tables-saveoutput:
# Generated by ip6tables-save v1.6.0 on Mon Feb  5 16:52:39 2018
*nat
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:OUTPUT ACCEPT [6:584]
:POSTROUTING ACCEPT [0:0]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d ::1/128 -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d ::1/128 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s fd00:dead:beef::/48 ! -o br-43960fd776fc -j MASQUERADE
-A POSTROUTING -s fd00:dead:beef::/48 ! -o br-43960fd776fc -j MASQUERADE
-A DOCKER -i br-43960fd776fc -j RETURN
COMMIT
# Completed on Mon Feb  5 16:52:39 2018
# Generated by ip6tables-save v1.6.0 on Mon Feb  5 16:52:39 2018
*filter
:INPUT ACCEPT [6:400]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [15:1312]
:DOCKER - [0:0]
:DOCKER-ISOLATION - [0:0]
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o br-43960fd776fc -j DOCKER
-A FORWARD -o br-43960fd776fc -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i br-43960fd776fc ! -o br-43960fd776fc -j ACCEPT
-A FORWARD -i br-43960fd776fc -o br-43960fd776fc -j ACCEPT
-A DOCKER-ISOLATION -j RETURN
COMMIT
# Completed on Mon Feb  5 16:52:39 2018
  • ping6 2001:4860:4860::8888 from within docker run --rm --net=ipv6net -it alpine ash and from host are the same:
PING 2001:4860:4860::8888 (2001:4860:4860::8888): 56 data bytes
^C
--- 2001:4860:4860::8888 ping statistics ---
2 packets transmitted, 0 packets received, 100% packet loss

I really think this is a great project, unfortunatly I didn't get it to work yet.

Sorry about the late reply, but setting some sysctl properties (mentioned below) solved this issue for me. I am using Amazon's default AMI for ec2 so these commands should work on RedHat-like OSes. This part of my shell script to setup the host machine is relevant here:

echo -e "\nSetting sysctl properties for IPv6 configuration..."
cat >> /etc/sysctl.conf << EOF
net.ipv6.conf.eth0.accept_ra = 2
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1
EOF

echo -e "\nSetting IPv4 forward property to true..."
sed -i "s/net.ipv4.ip_forward = 0/net.ipv4.ip_forward = 1/g" /etc/sysctl.conf

echo -e "\nSysctl property values after configuring:"
sysctl -p

echo -e "\nSetting docker config for IPv6..."
touch /etc/docker/daemon.json
cat >> /etc/docker/daemon.json << EOF
{
  "ipv6": true,
  "fixed-cidr-v6": "fd00::/48"
}
EOF

echo -e "\nRestarting docker..."
service docker restart

echo -e "\nStarting Docker-IPv6NAT container with auto-restart in privileged mode..."
docker run --name=ipv6nat -d --restart=always -v /var/run/docker.sock:/var/run/docker.sock:ro --privileged --net=host -v /lib/modules:/lib/modules:ro robbertkl/ipv6nat

Just adding this here in case it might help others who come across the same problem. cc: @MorbZ

Thanks @robbertkl for creating this useful utility and for trying to help. :)
I have another question, would you consider this utility to be production ready?

I'm sorry, I've missed your last comment @MorbZ

Indeed, the problem is with *.forwarding on IPv6, it disables accepting router advertisements even if *.accept_ra is set to 1. Use a special value of 2 to set it to always accept router advertisements, even if forwarding is enabled. See for example this link.

In the last couple of weeks I had a couple of similar questions from AWS users, so I will add these instructions to the README, in order to help others.

As for production: I use it in production myself. The tool itself has no active role in handling any traffic, since it just sets iptables rules similar to docker. That being said, IPv6 connectivity isn't that important in my production setup, and you might want to wait for this functionality to arrive in Docker itself (although it's taking a while).

@robbertkl: Not sure if this is the best place to ask this, but could you share some insight on how docker-ipv6nat is different from the following iptables rule?

ip6tables -t nat -A POSTROUTING -s fd00::/48 -j MASQUERADE

Hi @amjd, docker-ipv6nat adds a lot more rules than that, the same rules that Docker adds for IPv4. Among other things, it creates rules for published ports (docker run -p 3000:80 ...).

@robbertkl Thanks the for clarification. :)