# Understanding iptables rules added by docker **URL:** \ **Category:** General\ **Tags:** docker\ **Created:** [June 28, 2019, 11:33pm UTC](https://forums.docker.com/t/understanding-iptables-rules-added-by-docker/77210 "2019-06-28T23:33:42Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![rpal](https://sea3.discourse-cdn.com/docker/user_avatar/forums.docker.com/rpal/32/44222_2.png) [@rpal](https://forums.docker.com/u/rpal)\ **Post date:** [December 20, 2023, 9:19am UTC](https://forums.docker.com/t/understanding-iptables-rules-added-by-docker/77210/3 "2023-12-20T09:19:59Z")
Re the isolation stages - it is not apparent when you only have a single docker network (called docker0 by default), but more apparent if you have multiple networks. Then isolation stage 1 will send any container-originating traffic that is not destined to the same container to stage 2. The stage 2 will reject any traffic targeting a container. So, in effect, stage 1+2 prevents containers on different docker networks to communicate with each other (but allows containers to communicate with the outside world, at this point). (Slightly different thing: It _is_ possible for a container to be part of two different networks. Then docker will arrange two virtual ethernet devices inside the container, one bound to the bridge of one network, other to other, with appropriate subnet routing set up. So the network in this case will traverse under the specific bridge directly, and not leave from the bridge to the host and then say come back on the other bridge. AFAIU). See also [linux - Why does docker bypass ufw rules one time and another time not? - Server Fault](https://serverfault.com/questions/968189/why-does-docker-bypass-ufw-rules-one-time-and-another-time-not/1150083#1150083) on how you can generally debug what is happening, with network namespaces, packet tracing etc. --- _[View the full topic](https://forums.docker.com/t/understanding-iptables-rules-added-by-docker/77210)._