The firewall config migration that renames groups with invalid names (firewall/6-to-7) remembers each new name by the old name only, not by group type. When two group types use the same invalid name and get different new names, rules that reference the earlier group are silently rewritten to point at an unrelated group.

What were you attempting to achieve?

Upgrade a pre-1.4 configuration that contains firewall groups with invalid names, and have every rule keep matching the group it referenced before the upgrade.

Configuration used

A pre-1.4 style config, loaded on a current rolling image:

firewall {
    group {
        address-group bad_name {
            address 198.51.100.1
        }
        address-group bad+name {
            address 192.0.2.1
        }
        port-group bad+name {
            port 80
        }
    }
    name TEST1 {
        default-action drop
        rule 10 {
            action accept
            destination {
                group {
                    port-group bad+name
                }
            }
            protocol tcp
            source {
                group {
                    address-group bad+name
                }
            }
        }
    }
}

What did you expect to happen?

Both bad+name groups are renamed without losing their identity. Rule 10 still uses the 192.0.2.1 address-group as its source and the port-group on port 80 as its destination.

What actually happens

The address-group bad+name becomes bad_name_ (because bad_name already exists in that type), while the port-group bad+name becomes bad_name. The migration stores both under the single key bad+name, so the port-group's entry wins. Rule 10's source is then rewritten to bad_name — the unrelated address-group containing 198.51.100.1 — instead of bad_name_:

set firewall group address-group bad_name address '198.51.100.1'
set firewall group address-group bad_name_ address '192.0.2.1'
set firewall ipv4 name TEST1 rule 10 source group address-group 'bad_name'      # wrong

The rule now matches different addresses than before the upgrade. There is no error at migration or commit time.

The trigger is narrow: the same invalid name in two group types and different resulting names (for example because one type already has a group with the sanitized name). If both types sanitize to the same name the result is correct.

Root cause

In src/migration-scripts/firewall/6-to-7 the dict of renamed groups is written as translated_dict[group_name] = new_group_name while walking every group type, and read back as translated_dict[translated_group_name] when rewriting rule references. Neither side uses the group type, but the new name is only unique within a type. The rule reference already carries its type (the key under group), so the lookup can be keyed by (group_type, group_name).

Environment

VyOS version: rolling (reproduced on an image built from rolling at 79e78a499)
Affects configs upgraded through this migration; configs that already ran it are not repaired by the fix (the original names are gone, so a repair migration could not tell which references were wrong)

Prior art

Searched vyos.dev for "firewall group name migration" and the vyos/vyos-1x GitHub issues and PRs for "firewall migration group name invalid". Nothing describes this bug. The closest item is T8282 (closed) — it reports a migration failure for a network-group name with a trailing comma and added the name normalization; it does not mention a collision across group types or rule references pointing at the wrong group.