fix(networking): firewall policy region duplication, lock collisions, and secondary-location defaults

[oZakari]

Summary

Fixes a cluster of related bugs in the ALZ networking modules around firewall-policy naming and resource-lock default names. Supersedes #1159 (KiZach's lock-collision fix is included as a commit in this PR with original authorship preserved).

Bug 1 — vWAN: region duplicated in firewall policy name

vwanConnectivity.bicep auto-suffixes the hub location to parAzFirewallPoliciesName:

name: hub.?parAzFirewallPolicyCustomName ?? '${parAzFirewallPoliciesName}-${hub.parHubLocation}'

If a customer's parameters file already contains the region in parAzFirewallPoliciesName (e.g. alz-azfwpolicy-eastus), the location is appended a second time, producing names like alz-azfwpolicy-eastus-eastus.

Fix: make the name expression idempotent for both PerRegion and SharedGlobal deployment styles — only append -${hub.parHubLocation} when the name does not already end with it. Backward-compatible.

parAzFirewallPoliciesName	hub location	Resulting name
alz-azfwpolicy	eastus	alz-azfwpolicy-eastus (unchanged)
alz-azfwpolicy-eastus	eastus	alz-azfwpolicy-eastus (was alz-azfwpolicy-eastus-eastus)

Bug 2 — vWAN: firewall policy lock collision (closes #1159)

Two problems with resFirewallPoliciesLock / resFirewallPoliciesLockSharedGlobal in vwanConnectivity.bicep:

1. resFirewallPoliciesLock is missing the parAzFirewallPolicyDeploymentStyle == 'PerRegion' guard, so in SharedGlobal mode it tries to scope to an empty array — produces InvalidTemplate errors.
2. PerRegion and SharedGlobal locks share the same default name suffix (-lock), causing collisions when both code paths are evaluated.

Fix (cherry-picked from @KiZach #1159):

• Add the PerRegion guard to resFirewallPoliciesLock.
• Disambiguate default lock names: -perregion-lock and -sharedglobal-lock.

Bug 3 — hubNetworking-multiRegion.bicep: secondary-location defaults reference primary location

Defaults for the secondary-location firewall and firewall policy referenced ${parLocation} instead of ${parSecondaryLocation}:

// before
param parAzFirewallNameSecondaryLocation         string = '${parCompanyPrefix}-azfw-${parLocation}'
param parAzFirewallPoliciesNameSecondaryLocation string = '${parCompanyPrefix}-azfwpolicy-${parLocation}'
// after
param parAzFirewallNameSecondaryLocation         string = '${parCompanyPrefix}-azfw-${parSecondaryLocation}'
param parAzFirewallPoliciesNameSecondaryLocation string = '${parCompanyPrefix}-azfwpolicy-${parSecondaryLocation}'

When defaults were accepted, primary and secondary firewall / firewall-policy resources resolved to the same name and collided in ARM.

Bug 4 — hubNetworking-multiRegion.bicep: secondary VNet lock referenced primary VNet

resVirtualNetworkLockSecondaryLocation defaulted to '${resHubVnet.name}-lock' instead of '${resHubVnetSecondaryLocation.name}-lock'. With default lock names, the primary and secondary VNet locks collided.

Bug 5 — hubNetworking-multiRegion.bicep: defensive lock-name disambiguation

Renamed default firewall policy lock names to -primary-lock / -secondary-lock to harden against future regressions of the kind in Bug 2.

Files changed

• infra-as-code/bicep/modules/vwanConnectivity/vwanConnectivity.bicep
  • Idempotent name expression for resFirewallPolicies and resFirewallPoliciesSharedGlobal.
  • Updated parameter description for parAzFirewallPoliciesName.
  • Deployment-style guard on resFirewallPoliciesLock; -perregion-lock / -sharedglobal-lock default names.
• infra-as-code/bicep/modules/hubNetworking/hubNetworking-multiRegion.bicep
  • parAzFirewallNameSecondaryLocation and parAzFirewallPoliciesNameSecondaryLocation defaults now use parSecondaryLocation.
  • resVirtualNetworkLockSecondaryLocation default name now references resHubVnetSecondaryLocation.
  • Firewall policy lock default names disambiguated (-primary-lock / -secondary-lock).

Generated docs (generateddocs/*.bicep.md) are produced by the psdocs-mdtogit workflow on merge.

Credits

• vWAN lock collision fix authored by @KiZach in fix: AzureFirewallPolicyLock collision #1159 (cherry-picked, original authorship preserved).