Access Control List Rule Fails to Trigger for VPN Traffic

This article explains why an Access Control List (ACL) rule may not trigger as expected when traffic originates from a Virtual Private Network (VPN), affecting request attributes like user agent and IP address.

• Access Control List (ACL)

The root cause of this issue is typically one of three scenarios involving VPNs:

VPN services can alter or mask various attributes of an incoming HTTP request. Commonly affected attributes include:

1. IP Address: The primary function of a VPN is to mask the user's true IP address and replace it with an IP from the VPN provider's network. An ACL rule designed to allow or block a specific IP or IP range will not match if the user is on a VPN.

2. Geolocation Data: Since the user's IP address is masked, any geolocation data derived from it (such as country, city, or region) will reflect the location of the VPN server, not the user. ACL rules based on geography will therefore not evaluate correctly.

3. User Agent: Many commercial VPNs modify or remove the User-Agent header for privacy reasons. When the header is altered, the value received by the system no longer matches the value specified in the ACL rule.

Refer to Tenant Access Control Lists documentation for detailed information on configuring tenant traffic ACLs. To troubleshoot this issue, follow these steps:

1. Verify Request Attributes: Confirm whether the VPN is altering the expected request attributes. This can be done by using a public "What is my IP?" or "What is my user agent?" tool to inspect the request data with the VPN enabled and disabled. If the IP address, location, or user agent string is different, the VPN is the cause of the mismatch.

2. Review All ACL Rules: Examine the complete set of configured ACL rules to ensure there are no conflicting or overlapping rules that might be taking precedence over the intended rule.

3. Use a Correctly Formatted Rule: Ensure the ACL rule is formatted correctly. For example, to block requests from a specific user agent, the rule should use the deny list and specify the user_agent attribute. The user_agent must be the one sent by the client. Auth0 dashboard logs can shorten the user agent and, therefore, shouldn't be used.

{
  "description": "BlockAUserAgent",
  "active": true,
  "priority": 1,
  "rule": {
    "match": {
      "user_agents": [
        "BadBot/1.0.0"
      ]
    },
    "scope": "management",
    "action": {
      "block": true
    }
 }
}

4. Allow for Propagation Time: After creating or updating an ACL rule, wait a few minutes before testing. It can take a short period for the changes to propagate throughout the system.