Indeed routed
sounds like your best bet at the moment as it offers basic, controlled connectivity without any bells and whistles (leaving you fully in control of it). The biggest downside of routed
, and why we use bridged
by default is that routed
doesn’t support broadcast/multicast and thus doesn’t support automatic IP configuration, and requires manual configuration inside the instance.
But this is what is was designed for anyway, situations where you want to statically pass a specific set of IPs into an instance, without needing to route larger prefixes to your host.
WRT to ACLs, we discussed this over at Network ACLs possible on routed devices? - #4 by tomp
But to summarise:
- OVN networks support the full ACL functionality (including intra-network filtering). But OVN is quite a bit more complex and has more “moving parts” so not ideal for smaller setups (but perfectly possible). It does require a shared uplink network for each LXD host so that the virtual route IPs can be announced from any LXD host. See How to configure network ACLs - LXD documentation and LXD network ACLs - YouTube
- Bridged networks don’t support intra-network filtering (because netfilter doesn’t support providing ingress and egress port at the same time for a single rule). They do support filtering at the boundary between the bridge and the host though. See Prevent cross-talk - #8 by tomp for an example. Also see other limitations here How to configure network ACLs - LXD documentation
- You can use the
host_name
setting onrouted
NICs to allow for each NIC to have a predictable/known host-side interface name. This should help with manual firewalling as you can reference that interface in your rules. E.g.lxc config device set <instance> eth0 host_name=foo
See Type: nic - LXD documentation