Forum Discussion
How To Handle Dynamic IP Addresses Of Clients?
With most users having dynamic Ip addresses how does one handle the Azure Firewall?
I do not think setting a range for the IP's is useful because different ISP's have different ranges...
What is the solution, VNET Peering? Use a VPN/ Virtual Network Service? At another additional unnecessary cost & further complicating things.
It would be helpful if the Azure Security pinned thread contained content on the options of security implementation within Azure.
2 Replies
Dynamic client IP addresses cannot be effectively controlled through Azure Firewall rules that rely on static IP ranges. To ensure secure and predictable access, organizations should adopt identity-based authentication with Azure Active Directory, implement secure network tunneling solutions such as VPN or ExpressRoute, or leverage trusted connectivity services like Azure Bastion. These approaches provide a more reliable and scalable alternative to dynamic IP whitelisting.
https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/configure-public-ip-firewall
https://learn.microsoft.com/en-us/azure/firewall/firewall-known-issues
https://learn.microsoft.com/en-us/azure/azure-sql/database/connectivity-settings?view=azuresql&tabs=azure-portal
- AnkitDyeoniaOccasional Reader
Handling dynamic IP addresses for clients in Azure Firewall is a common challenge, especially since traditional firewall rules rely on static ranges that change frequently with ISPs.
While you mentioned that VPNs or VNET Peering seem like unnecessary complications, they are often the standard for a reason: security and reliability. However, depending on your specific use case (e.g., administrative access vs. general user access), there are several ways to handle this.
Solution 1: If your goal is to handle administrative access (RDP/SSH) for clients with dynamic IPs, Azure Bastion is the cleanest solution. It provides RDP/SSH access via SSL (port 443) directly through the Azure Portal. You don't need to allow any client IP addresses in the Azure Firewall. The client only needs to log into the Azure Portal. It eliminates the need to manage a VPN but does have a per-hour cost.
Solution 2: If you are trying to let users access a web application, instead of filtering by IP, use a WAF on Azure Front Door or Application Gateway. You can filter by geographic region or use identity-based access (like Entra ID/Azure AD) rather than relying on volatile IP addresses.
Solution 3: If you strictly want to use Azure Firewall and don't want a VPN, you can automate the update of firewall rules. Create a small script (Azure Logic App or PowerShell function) that clients can trigger. When they click a specific link or run a local script, it detects their current public IP and updates the Azure Firewall "Allow" rule. This is technically hacky and can lead to a messy firewall policy if not cleaned up (e.g., setting the rule to expire after 8 hours).
Solution 4: While you noted this adds complexity, a Point-to-Site (P2S) VPN is the industry standard for dynamic IPs. The Azure Firewall only needs to trust the Internal VPN Subnet (a static private range). It doesn't care what the client's public ISP IP is. Yes, it requires a Gateway and client-side setup, but it removes the IP-chasing headache entirely.
If you are managing servers, Azure Bastion is your best bet to avoid IP management. If you are providing broad network access to employees, a P2S VPN is the most stable path.