Share via

How to restrict /admin path access to VPN users while keeping the rest of the application publicly accessible?

Hariprasath Durairaj 0 Reputation points
2026-03-04T17:41:34.54+00:00

I have an application hosted behind an Azure Application Gateway with WAF enabled and accessible through a public domain.

The requirement is:

The main application (e.g., https://example.com) should be accessible to everyone on the internet.

The administrative path (e.g., https://example.com/admin) should be accessible only to users connected through a VPN.

Users who are not connected to the VPN should not be able to access /admin.

To achieve this, I created a custom WAF rule with logic similar to:

RequestUri BeginsWith /admin
AND
RemoteAddr NOT IN <VPN address range>
Action: Block

However, the Application Gateway appears to see the client’s public IP instead of the VPN IP, so the rule does not behave as expected.

What is the recommended approach to enforce that only VPN users can access /admin, while the rest of the application remains publicly accessible?

Azure Web Application Firewall

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Praveen Bandaru 10,720 Reputation points Microsoft External Staff Moderator
    2026-03-05T01:18:26.94+00:00

    Hello Hariprasath Durairaj

    I understand that you’re aiming to do make the app publicly accessible but restrict “/admin” to VPN users—is a common setup. However, using a single public listener with a WAF rule based on source IP isn’t reliable because VPN users’ private IPs are NAT’d, so only the public IP is visible.

    A better solution is to use Application Gateway v2 with path-based routing and two frontend IPs:

    1. Set up two frontend IPs on your Application Gateway:
      • One public frontend (already used for https://example.com).
      • One private frontend with an internal VNet IP.
    2. Create two HTTP listeners:
      • “Public-listener” on the public frontend, port 443.
      • “Private-listener” on the private frontend, also port 443.
    3. Add a path-based routing rule:
      • Paths starting with /admin go to the backend via the Private-listener.
      • All other paths go to the backend via the Public-listener.
    4. Connect VPN clients to the VNet where the Application Gateway is deployed. This way, only VPN users can access “/admin,” while other routes remain public.

    This avoids relying on WAF source-IP matching, allows you to keep WAF policies on both listeners, and ensures “/admin” is only accessible on the private network.

    If you need more info on configuring the second frontend IP or the path-based rule in Azure, let me know.

    0 comments
  2. Q&A Assist
    2026-03-04T17:41:50.88+00:00
    AI generated content. This question contains an answer created with AI from Q&A Assist. Learn more

    Use the VPN as a network boundary and enforce access to /admin at the origin or network layer, not by trying to match a “VPN IP” on the Application Gateway WAF.

    Key points from the WAF behavior:

    • For IP-based rules, WAF uses RemoteAddr (client IP from X-Forwarded-For) or SocketAddr (source IP seen by WAF).
    • If users connect via a VPN that terminates before Azure, the public IP seen by Application Gateway will still be the user’s internet egress IP, not a “VPN IP” in Azure. So a WAF rule on RemoteAddr cannot reliably distinguish “VPN vs non‑VPN” users in that scenario.

    Recommended approaches:

    1. Terminate VPN in Azure and restrict by source IP at the origin/network
      • Place the admin endpoint on a backend reachable only from a private network (for example, via Azure VPN Gateway or ExpressRoute into a VNet).
      • Use NSGs or firewall rules on the backend subnet/VMs to allow access to /admin only from the VPN address space.
      • Keep the public Application Gateway listener for the main site, but route /admin to a backend that is only reachable from the VPN network.
      • This aligns with the general guidance to lock down origins and restrict inbound traffic to trusted sources only.
    2. Split admin and public surfaces and protect admin with network controls
      • Host the admin UI on a separate site or path that is not exposed to the public internet (for example, separate listener or separate Application Gateway/backend).
      • Use NSGs, private endpoints, or internal-only Application Gateway to ensure that only VPN-connected clients can reach that admin surface.
    3. Use WAF rules for additional hardening, not primary VPN enforcement
      • Once the admin surface is reachable only from the VPN network at the network layer, WAF custom rules can still be used for extra checks (for example, rate limiting, user-agent filtering, or additional IP allow/deny lists).
      • WAF custom rules can match on RemoteAddr or headers, but they should not be the only control for “VPN-only” access when the VPN is not terminating in Azure.
    4. If using Azure Front Door in front of Application Gateway
      • When Front Door is in front of Application Gateway, follow the best practice of validating the X-Azure-FDID header in a custom WAF rule so that only Front Door can reach the Application Gateway.
      • Then apply the same pattern: keep /admin on an origin that is reachable only from the VPN network, and use WAF rules for additional filtering.

    In summary, the correct pattern is to enforce “VPN-only” access to /admin by ensuring that the admin endpoint is only reachable from the VPN address space at the network/origin layer (NSGs, private endpoints, internal gateways), and then use WAF custom rules as a secondary control. Relying on WAF IP matching alone cannot work if the VPN does not terminate in Azure in a way that changes the source IP seen by Application Gateway.

    References:

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.