Policy for FORWARD Chain should be DROP

[McBane87]

Hi,

I'm using your docker image, because it tries to create the same iptables rules docker does for ipv4. I wanted to have the same level of isolation. And your solution is nearly doing this, but I realized one difference. Docker, in ipv4 tables, is setting the policy in FORWARD chain to DROP, like this:

iptables -P FORWARD DROP

Unfortunately, your solution isn't doing this. Because if I investigate ip6tables -S, I can see the following:

-P FORWARD ACCEPT

Is there any reason for this? Or did you just forgot to include this?
Are you maybe willing to include this?

The background story, which was leading me to this issue

I've just created another docker network bridge named public0 having an ipv4 and ipv6 network.

docker network create \
        --subnet 10.168.1.0/24 \
        --gateway 10.168.1.1 \
       --ipv6 \
        --subnet fd00:10:168:1::/64 \
       --gateway fd00:10:168:1::1 \
        --opt com.docker.network.bridge.name=public0 \
        --opt com.docker.network.bridge.enable_ip_forwarding=true \
        --opt com.docker.network.bridge.enable_ip_masquerade=true \
        --opt com.docker.network.bridge.enable_icc=true \
        public0

Then I added those new ip addresses to my routers (fritzbox) static routing table, so I would be able to reach the networks directly. Something like this

10.168.1.0/24 via 192.168.1.50
fd00:10:168:1::/64 via fd00:192:168:1::50

After that I tried to ping a container from another computer (not the docker server), using ipv4, inside this public0 network.
Result: Not working. Solution: Allow connection using iptables:

iptables -I DOCKER-USER -d 10.168.1.0/24 -j ACCEPT

Now I tried the same for ipv6 and for my surprise I was able to ping. Then I compared the rules of both outputs (iptables -S and ip6tables -S) and finally found the reason for this. Docker changes the policy of the FORWARD chain to DROP. Your solution isn't.