LXD 3.18 - security.mac_filtering on bridged nic fails

LXD
1

Hi,

I’m currently experiencing an issue where containers having bridged nic devices with security.mac_filtering set to true fail to start. The machine is running an up to date Ubuntu 18.04 and the problem is encountered with lxd 3.18 coming from snap and installed from the release tarball. NICs are attached to unmanaged bridges and the following error message is displayed:

Error: Common start logic: Failed to start device 'eth0': No such object
Try `lxc info --show-log contnr` for more info

Any help would be greatly appreciated. :slight_smile:

Thanks

2

Can you show us the container’s config:

lxc config show <container> --expanded

Thanks
Tom

3

I suspect this is related to the IP filtering feature, that requires static IP allocation and therefore can only work with a managed bridge. However in principle I believe MAC filtering only could be made to work with an unmanaged bridge. Either way its either a bug/improvement or the validation needs improving.

@stgraber would you expect MAC filtering feature to be usable with an unmanaged bridge?

4

It’s the second time I’m using that configuration and it worked with 3.16 or 3.17. Writing this makes me realize that I had a similar issue on another system where I had to disable mac filtering to be able to launch containers. :thinking: I’ll double check if it’s a combination of setting hwaddr && security.mac_filtering and report back. Then I’ll downgrade to 3.17 and 3.16 if I have too to check if it’s a regression.

edit: I’ll send that configuration when I have access to the system later today.

5

All right. Here’s the output of lxc config show --expanded cntr:

architecture: x86_64
config:
  limits.cpu.priority: "1"
  limits.memory: 4GiB
  limits.memory.enforce: hard
  limits.processes: "1024"
  security.devlxd: "false"
  security.idmap.base: "10100000"
  security.idmap.isolated: "true"
  security.idmap.size: "65536"
  security.nesting: "false"
  security.privileged: "false"
  volatile.base_image: 35b077a81e4100496258bbf59f25f78ba6f06595719541e65d97427a75ed485c
  volatile.idmap.base: "10100000"
  volatile.idmap.current: '[{"Isuid":true,"Isgid":false,"Hostid":10100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10100000,"Nsid":0,"Maprange":65536}]'
  volatile.idmap.next: '[{"Isuid":true,"Isgid":false,"Hostid":10100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.idmap: '[{"Isuid":true,"Isgid":false,"Hostid":10100000,"Nsid":0,"Maprange":65536},{"Isuid":false,"Isgid":true,"Hostid":10100000,"Nsid":0,"Maprange":65536}]'
  volatile.last_state.power: STOPPED
devices:
  eth0:
    hwaddr: 00:16:3e:00:01:0b
    limits.egress: 8Mibit
    name: eth0
    nictype: bridged
    parent: br01
    security.mac_filtering: "true"
    type: nic
  root:
    path: /
    pool: default
    size: 32GiB
    type: disk
ephemeral: false
profiles:
- cntr
stateful: false
description: ""

I’m currently compiling 3.17 to test against it.

6

Okay, quick update:

  • containers fail to start when an unmanaged-bridged nic has security.mac_filtering set to true – hwaddr has no impact;
  • it fails on 3.17 and 3.18 so probably no regression here;
  • filtering works with a managed bridge.

At this point, I doubt I can make this work with unmanaged bridges in time so I’ll redesign the virtual network infrastructure instead.

In any case, I’m not sure there’s any reason to not have mac filtering work on unmanaged bridges. Maybe I’m missing something, but

ebtables -t filter -A INPUT -s ! co:nt:ai:ne:rm:ac -i vethX -j DROP
ebtables -t filter -A FORWARD -s ! co:nt:ai:ne:rm:ac -i vethX -j DROP

should suffice. The only reason why it’s not reasonable to do this manually is that vethX is random and so would be better handled by lxd.

Thanks for the help.

edit: I’m not sure how to close this properly.

7

@pgregoire that sounds like a bug to me, or at least a simple improvement.

@stgraber is there any reason you can think of why MAC filtering shouldn’t work on an unmanaged bridge, if not I think I can re-work the nic code a little to allow this.

8

Could you log an issue over at https://github.com/lxc/lxd/issues and I’ll take a look.

9

Nope, mac filtering should be fine, we don’t really need any knowledge of the underlying bridge to set it up.

10

Cool, have added a PR here https://github.com/lxc/lxd/pull/6358

11

Awesome, thanks a lot! :sunglasses: