lxd bridge interferes with tenant networks

[Fairbanks.]

Hello,

I have deployed OpenStack using juju with the openstack bundle.
This bundle uses LXD containers. The setup of these LXD containers create a bridge interface for NAT usage for these LXD's.

In my deployment this LXD network is located on 10.0.0.0/24 on all the machines, the neutron-gateway and several nova-compute nodes.

This produces several iptable rules, like postrouting and forwarding for this network.

Now, if i start an kvm instance on one of the compute nodes which has LXD containers running on the host, and i create a tenant network in that same subnet, the instance doesn't work, because its traffic is being altered by the iptable rules.

I don't know if this causes any security issues, but it at least means that tenant networks which will be on that same subnet as the lxd network will fail to work.

For more information please let me know.

[Ryan Beisner (1chb1n)]

I believe this is a duplicate of existing bug: https://bugs.launchpad.net/bugs/1614364.

[Fairbanks. (fairbanks)]

I think it kinda looks like the same. But it is more about the containers them selfs.
And if those containers need a fully bridged network without the dhcp solution lxd gives it.

In this case i don't know if that is comparable with that bug.
This has more to do with the iptables and openvswitch if you look at openstack, or to lxd if you look at the bridge part. So i don't know where to place this bug actually.

1.
It could be for the lxcontainers, because there is no interface defined for the lxdbr0 network in the postrouting, which will trigger every subnet that is defined for the lxd bridge even though it didn't pass that interface and went via kvm/openvswitch.

2.
It could be for juju, because currently you arn't able to tell it how to configure the lxd network (That likely the bug 1614364)

3.
It also could be neutron/openvswitch maybe? Because that is configuring the network, iptables etc.. for the instances. I don't know if there is a way to prevent these interfaces from passing any filtering/nat tables on the compute nodes and only make use of rules openvswitch created, because that could be a solution also, and maybe better security, or neutron/openvswitch should check for this, if there is a network on the compute nodes which could interfere with the tenant network range, and produce a sane error message.