Azure Firewall should be deployed with a management public IP to support future feature set

[SvenAelterman]

Description

As a TRE Administrator
I need every firewall deployment to have a management public IP
So that I can use upcoming Azure Firewall features

Acceptance criteria

• Deployments create a AzureFirewallManagementSubnet in the core virtual network, CIDR /26
• Create a second public IP for the firewall
• Specify the second public IP as the management IP.
• Provide a migration path which requires the firewall to be deallocated, additional IP assigned, and reallocated.

[jonnyry]

Does the Firewall Basic SKU support a management public IP? We are running our dev/test environments using the Firewall Basic SKU

[SvenAelterman]

Actually, the Basic SKU requires it. It is also currently required for forced tunneling.

[marrobi]

@tamirkamara FYI re forced tunneling.

Some of this exists - https://github.com/marrobi/AzureTRE/blob/397ab13d6e215e3902d8609175a4333f1c6825aa/core/terraform/network/network.tf#L142

[marrobi]

@SvenAelterman what features require this?

[SvenAelterman]

@SvenAelterman what features require this?

Not sure if they're already publicly announced.

[marrobi]

@SvenAelterman can you tick the first item off as already exists? And amend the issue title maybe?

[SvenAelterman]

@SvenAelterman can you tick the first item off as already exists? And amend the issue title maybe?

I should have known that, but I didn't. I wonder why the subnet already exists if it isn't used.

[marrobi]

@SvenAelterman its needed so could use Basic SKU

[SvenAelterman]

Great, that means most of the code is already there. Just need to remove any blockers for migration of an existing deployment.

[tamirkamara]

I believe this is the rest of it: #4238
Maybe will need some fine-tuning as currently used only when forced tunneling is requested.

[SvenAelterman]

That PR still puts conditions on when the fwmanagement public IP is created. It shouldn't anymore to be relevant for this issue. Only the condition on the route table should use the check for forced tunneling.

I also don't see how existing deployments could be updated because there's no code that deallocates the FW during this process. (Or do we want customers to do this manually?)