Skip to content

Commit f5483a4

Browse files
committed
some acrofixes
1 parent 8f32d18 commit f5483a4

File tree

1 file changed

+20
-19
lines changed

1 file changed

+20
-19
lines changed

articles/firewall/firewall-faq.yml

Lines changed: 20 additions & 19 deletions
Original file line numberDiff line numberDiff line change
@@ -57,7 +57,7 @@ sections:
5757
Azure Firewall is integrated with Azure Monitor for viewing and analyzing firewall logs. Logs can be sent to Log Analytics, Azure Storage, or Event Hubs. They can be analyzed in Log Analytics or by different tools such as Excel and Power BI. For more information, see [Tutorial: Monitor Azure Firewall logs](./firewall-diagnostics.md).
5858
5959
- question: How does Azure Firewall work differently from existing services such as NVAs in the marketplace?
60-
answer: Azure Firewall is a managed, cloud-based network security service that protects your virtual network resources. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. It is pre-integrated with third-party security as a service (SECaaS) providers to provide advanced security for your virtual network and branch Internet connections. To learn more about Azure network security, see [Azure network security](../networking/security/index.yml).
60+
answer: Azure Firewall is a managed, cloud-based network security service that protects your virtual network resources. It's a fully stateful firewall as a service with built-in high availability and unrestricted cloud scalability. It's pre-integrated with third-party security as a service (SECaaS) providers to provide advanced security for your virtual network and branch Internet connections. To learn more about Azure network security, see [Azure network security](../networking/security/index.yml).
6161

6262

6363
- question: What is the difference between Application Gateway WAF and Azure Firewall?
@@ -151,8 +151,8 @@ sections:
151151
152152
- question: How can I configure availability zones after deployment?
153153
answer: |
154-
The recommendation is to configure availability zones during the initial firewall deployment. However, in some cases it is possible to change availability zones after deployment. The prerequisites are:
155-
- The firewall is deployed in a VNet. It is not supported with firewalls deployed in a secured virtual hub.
154+
The recommendation is to configure availability zones during the initial firewall deployment. However, in some cases it's possible to change availability zones after deployment. The prerequisites are:
155+
- The firewall is deployed in a VNet. It isn't supported with firewalls deployed in a secured virtual hub.
156156
- The firewall's region [supports availability zones](../reliability/availability-zones-service-support.md).
157157
- All attached public IP addresses are deployed with availability zones. In the properties page of each public IP address, ensure the **availability zones** field exists and is configured with the same zones you configured for the firewall.
158158
@@ -176,7 +176,7 @@ sections:
176176
answer: Yes, you can use Azure Firewall in a hub virtual network to route and filter traffic between two spoke virtual network. Subnets in each of the spoke virtual networks must have a UDR pointing to the Azure Firewall as a default gateway for this scenario to work properly.
177177

178178
- question: Can Azure Firewall forward and filter network traffic between subnets in the same virtual network or peered virtual networks?
179-
answer: Yes. However, configuring the UDRs to redirect traffic between subnets in the same VNET requires additional attention. While using the VNET address range as a target prefix for the UDR is sufficient, this also routes all traffic from one machine to another machine in the same subnet through the Azure Firewall instance. To avoid this, include a route for the subnet in the UDR with a next hop type of **VNET**. Managing these routes might be cumbersome and prone to error. The recommended method for internal network segmentation is to use Network Security Groups, which don't require UDRs.
179+
answer: Yes. However, configuring the UDRs to redirect traffic between subnets in the same VNET requires more attention. While using the VNET address range as a target prefix for the UDR is sufficient, this also routes all traffic from one machine to another machine in the same subnet through the Azure Firewall instance. To avoid this, include a route for the subnet in the UDR with a next hop type of **VNET**. Managing these routes might be cumbersome and prone to error. The recommended method for internal network segmentation is to use Network Security Groups, which don't require UDRs.
180180

181181
- question: Does Azure Firewall outbound SNAT between private networks?
182182
answer: |
@@ -198,7 +198,7 @@ sections:
198198
answer: |
199199
- **URL** - Asterisks work when placed on the right-most or left-most side. If it is on the left, it can't be part of the FQDN.
200200
- **FQDN** - Asterisks work when placed on the left-most side.
201-
- **GENERAL** - Asterisks on the left-most side mean literally _anything_ to the left will match, meaning multiple subdomains and/or potentially unwanted domain name variations will be matched - see examples below.
201+
- **GENERAL** - Asterisks on the left-most side mean literally _anything_ to the left matches, meaning multiple subdomains and/or potentially unwanted domain name variations are matched - see examples below.
202202
203203
Examples:
204204
@@ -207,27 +207,27 @@ sections:
207207
|---------|---------|---------|---------|
208208
|TargetURL |`www.contoso.com` |Yes|`www.contoso.com`<br>`www.contoso.com/`|
209209
|TargetURL |`*.contoso.com` |Yes|`any.contoso.com/`<br>`sub1.any.contoso.com`|
210-
|TargetURL |`*contoso.com`|Yes |`example.anycontoso.com`<br>`sub1.example.contoso.com`<br>`contoso.com`<br>Warning: this usage of wildcard will also allow potentially undesired/risky variations such as `th3re4lcontoso.com` - use with caution.|
210+
|TargetURL |`*contoso.com`|Yes |`example.anycontoso.com`<br>`sub1.example.contoso.com`<br>`contoso.com`<br>Warning: this usage of wildcard also allows potentially undesired/risky variations such as `th3re4lcontoso.com` - use with caution.|
211211
|TargetURL |`www.contoso.com/test`|Yes|`www.contoso.com/test`<br>`www.contoso.com/test/`<br>`www.contoso.com/test?with_query=1`|
212-
|TargetURL |`www.contoso.com/test/*`|Yes|`www.contoso.com/test/anything`<br>Note: `www.contoso.com/test` will **not** match (last slash)|
212+
|TargetURL |`www.contoso.com/test/*`|Yes|`www.contoso.com/test/anything`<br>Note: `www.contoso.com/test` **doesn't** match (last slash)|
213213
|TargetURL |`www.contoso.*/test/*`|No| |
214214
|TargetURL |`www.contoso.com/test?example=1`|No| |
215215
|TargetURL |`www.contoso.*`|No| |
216216
|TargetURL |`www.*contoso.com`|No| |
217217
|TargetURL |`www.contoso.com:8080`|No| |
218218
|TargetURL |`*.contoso.*`|No| |
219219
|TargetFQDN |`www.contoso.com`|Yes|`www.contoso.com`|
220-
|TargetFQDN |`*.contoso.com`|Yes|`any.contoso.com`<br><br>Note: If you want to specifically allow `contoso.com`, you must include contoso.com in the rule. Otherwise, the connection will be dropped by default because the request will not match any rule.|
220+
|TargetFQDN |`*.contoso.com`|Yes|`any.contoso.com`<br><br>Note: If you want to specifically allow `contoso.com`, you must include contoso.com in the rule. Otherwise, the connection is dropped by default because the request doesn't match any rule.|
221221
|TargetFQDN |`*contoso.com`|Yes|`example.anycontoso.com`<br>`contoso.com`|
222222
|TargetFQDN |`www.contoso.*`|No| |
223223
|TargetFQDN |`*.contoso.*`|No| |
224224
225225
- question: |
226226
What does *Provisioning state: Failed* mean?
227-
answer: Whenever a configuration change is applied, Azure Firewall attempts to update all its underlying backend instances. In rare cases, one of these backend instances may fail to update with the new configuration and the update process stops with a failed provisioning state. Your Azure Firewall is still operational, but the applied configuration may be in an inconsistent state, where some instances have the previous configuration where others have the updated rule set. If this happens, try updating your configuration one more time until the operation succeeds and your Firewall is in a *Succeeded* provisioning state.
227+
answer: Whenever a configuration change is applied, Azure Firewall attempts to update all its underlying backend instances. In rare cases, one of these backend instances might fail to update with the new configuration and the update process stops with a failed provisioning state. Your Azure Firewall is still operational, but the applied configuration might be in an inconsistent state, where some instances have the previous configuration where others have the updated rule set. If this happens, try updating your configuration one more time until the operation succeeds and your Firewall is in a *Succeeded* provisioning state.
228228
229229
- question: How does Azure Firewall handle planned maintenance and unplanned failures?
230-
answer: Azure Firewall consists of several backend nodes in an active-active configuration. For any planned maintenance, we have connection draining logic to gracefully update nodes. Updates are planned during non-business hours for each of the Azure regions to further limit risk of disruption. For unplanned issues, we instantiate a new node to replace the failed node. Connectivity to the new node is typically reestablished within 10 seconds from the time of the failure.
230+
answer: Azure Firewall consists of several backend nodes in an active-active configuration. For any planned maintenance, we have connection draining logic to gracefully update nodes. Updates are planned during nonbusiness hours for each of the Azure regions to further limit risk of disruption. For unplanned issues, we instantiate a new node to replace the failed node. Connectivity to the new node is typically reestablished within 10 seconds from the time of the failure.
231231

232232
- question: How does connection draining work?
233233
answer: For any planned maintenance, connection draining logic gracefully updates backend nodes. Azure Firewall waits 90 seconds for existing connections to close. In the first 45 seconds, the backend node doesn't accept new connections, and in the remaining time it responds with `RST` to all incoming packets. If needed, clients can automatically re-establish connectivity to another backend node.
@@ -246,7 +246,8 @@ sections:
246246

247247
- question: How long does it take for Azure Firewall to scale out?
248248
answer: |
249-
Azure Firewall gradually scales when average throughput or CPU consumption is at 60%, or the number of connections usage is at 80%. For example, it starts to scale out when it reaches 60% of its maximum throughput. Maximum throughput numbers vary based on Firewall SKU and enabled features. For more information, see [Azure Firewall performance](firewall-performance.md).
249+
Azure Firewall gradually scales when average throughput or CPU consumption is at 60%, or the number of connections usage is at 80%. For example, it starts to scale out when it reaches 60% of its maximum throughput.
250+
Maximum throughput numbers vary based on Firewall SKU and enabled features. For more information, see [Azure Firewall performance](firewall-performance.md).
250251
251252
Scale out takes five to seven minutes.
252253
@@ -258,7 +259,7 @@ sections:
258259
259260
- question: How does Azure Firewall handle VM instance shutdowns during Virtual Machine Scale Set scale in (scale down) or fleet software upgrades?
260261
answer: |
261-
An Azure Firewall VM instance shutdown may occur during Virtual Machine Scale Set scale in (scale down) or during fleet software upgrade. In these cases, new incoming connections are load balanced to the remaining firewall instances and are not forwarded to the down firewall instance. After 45 seconds the firewall starts rejecting existing connections by sending TCP RST packets. After an additional 45 seconds the firewall VM shuts down. For more information, see [Load Balancer TCP Reset and Idle Timeout](../load-balancer/load-balancer-tcp-reset.md).
262+
An Azure Firewall VM instance shutdown might occur during Virtual Machine Scale Set scale in (scale down) or during fleet software upgrade. In these cases, new incoming connections are load balanced to the remaining firewall instances and aren't forwarded to the down firewall instance. After 45 seconds the firewall starts rejecting existing connections by sending TCP RST packets. After another 45 seconds the firewall VM shuts down. For more information, see [Load Balancer TCP Reset and Idle Timeout](../load-balancer/load-balancer-tcp-reset.md).
262263
263264
- question: Does Azure Firewall allow access to Active Directory by default?
264265
answer: |
@@ -269,7 +270,7 @@ sections:
269270
Yes, you can use Azure PowerShell to do it:
270271
271272
```azurepowershell
272-
# Add a Threat Intelligence allowlist to an Existing Azure Firewall
273+
# Add a Threat Intelligence allowlist to an Existing Azure Firewall.
273274
274275
# Create the allowlist with both FQDN and IPAddresses
275276
$fw = Get-AzFirewall -Name "Name_of_Firewall" -ResourceGroupName "Name_of_ResourceGroup"
@@ -287,9 +288,9 @@ sections:
287288
288289
- question: Why can a TCP ping and similar tools successfully connect to a target FQDN even when no rule on Azure Firewall allows that traffic?
289290
answer: |
290-
A TCP ping isn't actually connecting to the target FQDN. Azure Firewall doesn't allow a connection to any target IP address/FQDN unless there is an explicit rule that allows it.
291+
A TCP ping isn't actually connecting to the target FQDN. Azure Firewall doesn't allow a connection to any target IP address/FQDN unless there's an explicit rule that allows it.
291292
292-
TCP ping is a unique use case where if there is no allowed rule, the Firewall itself responds to the client's TCP ping request even though the TCP ping doesn't reach the target IP address/FQDN. In this case, the event is not logged. If there is a network rule that allows access to the target IP address/FQDN, then the ping request reaches the target server and its response is relayed back to the client. This event is logged in the Network rules log.
293+
TCP ping is a unique use case where if there's no allowed rule, the Firewall itself responds to the client's TCP ping request even though the TCP ping doesn't reach the target IP address/FQDN. In this case, the event isn't logged. If there's a network rule that allows access to the target IP address/FQDN, then the ping request reaches the target server and its response is relayed back to the client. This event is logged in the Network rules log.
293294
294295
295296
- question: Are there limits for the number of IP addresses supported by IP Groups?
@@ -301,21 +302,21 @@ sections:
301302

302303
- question: What is the TCP Idle Timeout for Azure Firewall?
303304
answer: |
304-
A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't user configurable, but you can contact Azure Support to increase the Idle Timeout for inbound and outbound connections up to 30 minutes. Idle Timeout for east-west traffic cannot be changed.
305+
A standard behavior of a network firewall is to ensure TCP connections are kept alive and to promptly close them if there's no activity. Azure Firewall TCP Idle Timeout is four minutes. This setting isn't user configurable, but you can contact Azure Support to increase the Idle Timeout for inbound and outbound connections up to 30 minutes. Idle Timeout for east-west traffic can't be changed.
305306
306307
If a period of inactivity is longer than the timeout value, there's no guarantee that the TCP or HTTP session is maintained. A common practice is to use a TCP keep-alive. This practice keeps the connection active for a longer period. For more information, see the [.NET examples](/dotnet/api/system.net.servicepoint.settcpkeepalive).
307308
308309
- question: Can I deploy Azure Firewall without a public IP address?
309-
answer: Yes, but you must configure the firewall in Forced Tunneling Mode. This configuration creates a management interface with a public IP address that is used by Azure Firewall for its operations. This public IP address is for management traffic. It is used exclusively by the Azure platform and can't be used for any other purpose. The tenant data path network can be configured without a public IP address, and Internet traffic can be forced tunneled to another Firewall or completely blocked.
310+
answer: Yes, but you must configure the firewall in Forced Tunneling Mode. This configuration creates a management interface with a public IP address that is used by Azure Firewall for its operations. This public IP address is for management traffic. It's used exclusively by the Azure platform and can't be used for any other purpose. The tenant data path network can be configured without a public IP address, and Internet traffic can be forced tunneled to another Firewall or completely blocked.
310311

311312
- question: Where does Azure Firewall store customer data?
312313
answer: Azure Firewall doesn't move or store customer data out of the region it's deployed in.
313314

314-
- question: Is there a way to automatically backup Azure Firewall and policies?
315+
- question: Is there a way to automatically back up Azure Firewall and policies?
315316
answer: Yes. For more information, see [Backup Azure Firewall and Azure Firewall Policy with Logic Apps](https://techcommunity.microsoft.com/t5/azure-network-security-blog/backup-azure-firewall-and-azure-firewall-policy-with-logic-apps/ba-p/3613928).
316317

317318
- question: Is Azure Firewall in secured virtual hubs (vWAN) supported in Qatar?
318-
answer: No, currently Azure Firewall in secured virtual hubs (vWAN) is not supported in Qatar.
319+
answer: No, currently Azure Firewall in secured virtual hubs (vWAN) isn't supported in Qatar.
319320

320321
- question: How many parallel connections can Azure Firewall support?
321322
answer: |

0 commit comments

Comments
 (0)