You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Now that your secure hub is fully operational, you can test connectivity by deploying a virtual machine in each spoke virtual network connected to the hub:
184
+
Now that your secure hub is fully operational, you can test connectivity by deploying a virtual machine in each spoke virtual network connected to the hub.
By default, the firewall policy blocks all traffic. To allow access to your test virtual machines, you must configure DNAT (Destination Network Address Translation) rules. These rules will enable you to connect to the VMs through the Azure Firewall's public IP address:
224
+
### Deploy Azure Bastion
225
+
226
+
Deploy Azure Bastion in the Spoke-01 virtual network to securely connect to the virtual machines without requiring public IP addresses or DNAT rules.
213
227
214
228
```azurepowershell-interactive
215
-
# Adding DNAT rules for virtual machines in the spokes
Next, configure example rules for your firewall policy. First, create a network rule to allow SSH traffic between the virtual networks. Then, add an application rule to permit Internet access only to the Fully Qualified Domain Name (FQDN) `ifconfig.co`, which returns the source IP address seen in the HTTP request:
238
+
> [!NOTE]
239
+
> Azure Bastion deployment can take approximately 10 minutes to complete.
240
+
241
+
By default, the firewall policy blocks all traffic. To allow access between spoke virtual machines and to the internet, you must configure firewall rules. First, create a network rule to allow SSH traffic between the virtual networks. Then, add an application rule to permit Internet access only to the Fully Qualified Domain Name (FQDN) `ifconfig.co`, which returns the source IP address seen in the HTTP request:
Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC2.Name | ft
251
264
```
252
265
253
-
Generate traffic from one virtual machine to the other and verify that it is filtered by Azure Firewall. Use SSH to connect to the virtual machines—accept the SSH fingerprint and enter the password you set during VM creation. In this example, you will:
266
+
Generate traffic from one virtual machine to the other and verify that it is filtered by Azure Firewall. Use Azure Bastion to connect to the virtual machines. In this example, you will:
254
267
255
-
- Send five ICMP echo requests (pings) from the VM in spoke1 to the VM in spoke2.
256
-
- Attempt a TCP connection on port 22 using the `nc` (netcat) utility with the `-vz` flags, which checks connectivity without sending data.
268
+
- Connect to spoke1-vm using Azure Bastion through the Azure portal
269
+
- Send five ICMP echo requests (pings) from the VM in spoke1 to the VM in spoke2
270
+
- Attempt a TCP connection on port 22 using the `nc` (netcat) utility with the `-vz` flags, which checks connectivity without sending data
257
271
258
272
You should observe that the ping requests fail (blocked by the firewall), while the TCP connection on port 22 succeeds, as allowed by the previously configured network rule.
259
273
260
-
```azurepowershell-interactive
261
-
# Connect to one VM and ping the other. It should not work, because the firewall should drop the traffic, since no rule for ICMP is configured
1. In the Azure portal, navigate to the **spoke1-vm** virtual machine.
277
+
2. Select **Connect** > **Connect via Bastion**.
278
+
3. Provide the username **azureuser** and upload the private key file generated earlier.
279
+
4. Select **Connect** to open an SSH session.
280
+
5. In the SSH session, run the following commands:
281
+
282
+
```bash
283
+
# Ping should fail (blocked by firewall)
284
+
ping $Spoke2VMPrivateIP -c 5
285
+
# SSH connectivity check should succeed (allowed by firewall)
286
+
nc -vz $Spoke2VMPrivateIP 22
265
287
```
266
288
267
-
You can also test Internet access through the firewall. HTTP requests using the `curl` utility to the allowed FQDN (`ifconfig.co`) should succeed, while requests to other destinations (such as `bing.com`) should be blocked by the firewall policy:
289
+
Replace `$Spoke2VMPrivateIP` with the actual private IP address of spoke2-vm (displayed in the PowerShell output).
268
290
269
-
```azurepowershell-interactive
291
+
You can also test Internet access through the firewall. HTTP requests using the `curl` utility to the allowed FQDN (`ifconfig.co`) should succeed, while requests to other destinations (such as `bing.com`) should be blocked by the firewall policy.
292
+
293
+
From the same SSH session on spoke1-vm:
294
+
295
+
```bash
270
296
# This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP of the FW
To confirm that the firewall is dropping packets as expected, review the logs sent to Azure Monitor. Since Azure Firewall is configured to send diagnostic logs to Azure Monitor, you can use Kusto Query Language (KQL) to query and analyze the relevant log entries:
If you want to see the logs for the application rules (describing allowed and denied HTTP connections) or change the way that the logs are displayed, you can try with other KQL queries. You can find some examples in [Azure Monitor logs for Azure Firewall](../firewall/firewall-workbook.md).
![prmerger-automator[bot]](https://avatars.githubusercontent.com/u/22479449?v=4&size=40){kind=avatar}
0 commit comments