An Azure network security service that is used to protect Azure Virtual Network resources.
Hello @Kshitij Mathur
You don't need full access to the customer's Azure subscription to troubleshoot or monitor Azure Firewall. You can handle this with Azure RBAC and Azure Monitor using least-privilege permissions.
First, one clarification: Azure Firewall logs aren't a real-time packet capture or live traffic console. Enable Azure Firewall resource logs through Diagnostic settings and send them to a destination such as a Log Analytics workspace, Storage Account, or Event Hub.
I would ask the customer to check:
Azure Firewall → Monitoring → Diagnostic settings
and configure the required firewall log categories to send to a dedicated Log Analytics workspace. Microsoft recommends using the newer structured Azure Firewall logs rather than enabling both the legacy and structured formats.
Once enabled, you can query traffic by source/destination IP, ports, protocols, rules, and actions from Log Analytics.
For example, depending on the enabled structured tables:
AZFWNetworkRule
| where TimeGenerated > ago(30m)
| where SourceIp == "10.10.10.10"
or DestinationIp == "10.10.10.10"
| project TimeGenerated,
SourceIp,
DestinationIp,
DestinationPort,
Protocol,
Action
| order by TimeGenerated desc
If the customer doesn't want to provide broad access, that's completely reasonable. Have them assign your support team access only to the Log Analytics workspace containing the firewall logs.
For read-only troubleshooting, you can use Log Analytics Data Reader to query permitted Log Analytics data. Microsoft also supports granular RBAC/custom roles when customers want to restrict access to particular workspace tables.
Alternatively, Monitoring Reader provides read access to monitoring data without allowing you to modify resources.
So a practical architecture would be:
This is much better than requesting Owner or Contributor access to the customer's entire environment.
If by "real time IP logs" you actually mean packet-level capture rather than firewall rule logs, that's a different requirement. Network Watcher provides network troubleshooting capabilities, but its permissions should likewise be scoped appropriately rather than granting full subscription access.
I'd therefore ask the customer to first enable Azure Firewall diagnostic logging and grant your team read-only access to the monitoring data only. If the logs are already enabled but aren't appearing, verify the selected diagnostic categories, destination workspace, and whether traffic is actually traversing the firewall before changing firewall rules.
Sharing these references with you:
Microsoft - Secure your Azure Firewall deployment
Microsoft - Azure Monitor roles, permissions, and security
Microsoft - Granular RBAC for Log Analytics
This approach gives your team the IP/traffic visibility needed for troubleshooting while allowing the customer to maintain control of the firewall and the rest of their Azure environment.
Help make this community better for everyone: if this answer resolved your issue, please accept it or leave an upvote. If not, share more details in a comment so we can continue the discussion and find the right solution.