Network ACLs possible on routed devices?

LXD
1

I don’t seem to be able to add a network.acls key to a routed device. Am I correct in presuming that the acls feature only applies to plain bridge and OVN networks at present?

Is there a roadmap plan to add support for routed devices? (goal is to have net devices where I can assign/enforce external IPV4s to the machine from outside the container, rather than inside)

I also hit some troubles trying to assign network.acls to an unmanaged bridge, ie where the host machine has a bridge with public IPV4 on it, and the container is a device attached to that bridge in order to get an external IP address. Is this a supported setup for net ACLs at present? (ie am I just getting the config wrong and it should be possible?)

Thanks

2

Because network ACLs require somewhere to store the associated rules for each ACL they can only be applied to managed networks. This is why they are not supported on routed NICs or unmanaged bridges - neither have an associated managed network.

There isn’t anything on the roadmap at this time to support ACLs for NICs without managed networks.

You can add firewall rules to the host directly though and use the host_name property of the routed NIC so that it has a predicable interface name on the host side.

3

That’s helpful. Thanks for taking the time to reply

This is probably a silly question, but I won’t learn without asking it… So, be gentle please…

I was watching this video:

  • LXD network ACLs - YouTube
    At around timestamp 7:14 he adds an acl to the device as defined within the instance config, so something like
lxc config device override u1 eth0 security.acls=demo

I guess I was wondering why this isn’t a valid place that could be used to store the associated rules?

4

So actually only ovn NICs support using security.acls at the NIC level.
The bridged NICs do not support this, and only support ACLs being assigned at the managed network level.

This is due to a limitation in the netfilter framework in the kernel not providing sufficient information when doing intra-bridge filtering, see How to configure network ACLs - LXD documentation

But in principle because the routed NICs do not have a bridge, and thus are not affected by intra-bridge filtering limtations, they could be made to be able to have ACLs associated to them.

But because they do not have a managed network to actually store the rules (the current underlying DB tables that store the rules are keyed to network ID), it would need a new set of DB tables, as well as API and CLI extensions in order to allow the rules to be created/managed at the NIC level before being able to be assigned to the NIC itself.

5

However we do support the concept of external networks (where they don’t actually set anything up on the host but rather are just presets of configuration info).

In principle routed NICs could be made to support using a physical network to get its parent interface setting and then that could be modified to allow storing ACL rules. As by that point it is effectively a managed network.

At the moment physical networks are just used for OVN uplink networks.