Comment 5 for bug 1554177

@Sergey, can you please clarify which exactly networks you mean?

In the bug description, you shown 'admin_fuelbr' and 'pub_subnet', but point to management and public networks. So, 'management' network means Fuel admin network 'admin/PXE'? Or it is OpenStack management network?

Anyway, it is the libvirt behaviour: networks are created in such way that there is *must* be connectivity between different networks thru the host's routing.

The rules that are in the description ' --reject-with icmp-port-unreachable' - not for network isolation. It just filters out the packets going from/to the bridge of a network which are not belong to the networks's CIDR:

# Allow forward *to* libvirt network only for existing connections
-A FORWARD -d 10.109.0.0/24 -o virbr112 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Allow forward *from* libvirt network 10.109.0.0/24
-A FORWARD -s 10.109.0.0/24 -i virbr112 -j ACCEPT

# Allow any packets only inside the libvirt network
-A FORWARD -i virbr112 -o virbr112 -j ACCEPT

# Reject any other packets.
-A FORWARD -o virbr112 -j REJECT --reject-with icmp-port-unreachable
-A FORWARD -i virbr112 -j REJECT --reject-with icmp-port-unreachable

So, if you try to access virbr112 directly *from* another libvirt network virbr113, your packets will be rejected by the rules for virbr113.

*But* if you try to access 10.109.0.0/24 addresses from another network, it *will* be accessible with host's routing table:
10.109.0.0/24 dev virbr112 proto kernel scope link src 10.109.0.1
10.109.2.0/24 dev virbr113 proto kernel scope link src 10.109.2.1

Please confirm that this issue is connected exactly to iptables rules, and provide more details:
 - how the networks are created/started (with fuel-qa system tests or with dos.py, or with some custom scripts that use virsh)
 - how exactly you check the presence of issue (to let us reproduce the check)
 - version of libvirt-bin package.