Skip to content

OVN Network ACLs: @internal and ACL-name subject selectors fail to allow intra-subnet traffic (while explicit CIDRs work) #18132

@nsakkos

Description

@nsakkos

Please confirm

  • I have searched existing issues to check if an issue already exists for the bug I encountered.

It is worth mentioning this relevant bug from incus, in case this is an OVN issue lxc/incus#1423

Distribution

Ubuntu

Distribution version

24.04

Output of snap list --all lxd core20 core22 core24 snapd

-

System info

driver_version: 6.0.6 | 8.2.2
kernel_version: 6.8.0-62-generic
server_version: 5.21.4
storage: ceph | cephobject

Instance log

n/a

Expected behavior

When applying OVN Network ACLs to allow all intra-project communication using

  • the @internal network subject selector (applied either to the network or instance NICs)
  • an ACL-name group selector (applied to instance NICs)
    should allow the instances to communicate with one another

Actual behavior

Instances are unable to communicate with each other, resulting in Connection refused.
Even when lxc network acl show <acl> confirms the rule is state: enabled and the instances correctly appear in the used_by list, the OVN firewall seem to be blocking the cross-instance traffic.

However, when the @internal or ACL-name selector is replaced with the explicit subnet CIDR (e.g., 10.171.2.128/26), the exact same traffic succeeds instantly.

Steps to reproduce

  1. Create an OVN network (acl-test) with a defined IPv4 subnet (e.g., 10.171.2.128/26).
  2. Create two instances attached to this network.

@internal issue

  1. Create a network ACL allowing ingress/egress for the @internal subject. lxc network acl rule add test-acl ingress action=allow source='@internal' destination_port=8201 protocol=tcp and lxc network acl rule add test-acl egress action=allow destination='@internal'

  2. Apply the ACL to the network

  3. Start a listener on Instance A

  4. Attempt to connect from Instance B (fails)

  5. Modify the ACL to use its own name as the source/destination (e.g., source=my-service-acls).

  6. Remove the ACL from the network, and apply it directly to the instances' NICs via profile (lxc profile device set default eth0 security.acls=my-service-acls).

  7. Verify instances show up in the ACL's used_by list.

  8. Attempt the nc test from Instance B to Instance A again (fails)

Workaround

  1. Modify the ACL, replacing the logical selectors with the explicit subnet: source=10.171.2.128/26.
  2. Attempt the nc test from Instance B to Instance A (succeeds)

**

instance_config.txt

**

An example of @internal used to allow traffic on 8201 (failing) and CIDR for 8200 (succeeding) https://pastebin.canonical.com/p/xBszSqXYYJ/

Information to attach

  • Any relevant kernel output (dmesg)
  • Instance configuration (lxc config show <instance> --expanded)
  • Main daemon log (at /var/log/lxd/lxd.log or /var/snap/lxd/common/lxd/logs/lxd.log)
  • If a lxc command fails, output of the command with --debug
  • Output of the daemon with --debug (or use lxc monitor while reproducing the issue)

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No fields configured for Bug.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions