In today’s distributed world the perimeter of an organization is no longer a single firewall at the edge of a data center. Users, services and devices connect from any location, over public clouds, through orchestrated container networks and via remote VPNs. This shift has driven security teams to adopt Zero Trust, a model that validates not only who you are but also where your device is located and what network it uses before granting access to critical resources.

One of the most effective ways to add an additional layer of verification is geofencing – the practice of allowing or denying traffic based on its geographic or network attributes such as country, city, or Autonomous System Number (ASN). When combined with strong device authentication (for example Device Trust certificates) geofencing can dramatically reduce the attack surface of your Device Trust access gateways.

This post explains how to harden access gateways with geofencing using Nginx and the ngx_http_geoip2_module. We will walk through obtaining free GeoIP data from MaxMind, configuring Nginx as a reverse proxy that blocks traffic by ASN, integrating geofence policies into modern identity providers like Authentik, and visualizing a example secure access flow. The examples are designed for Linux environments but can be adapted to any container or cloud platform.

Why Device Trust Matters in Modern Cloud Environments

• Devices now connect from home offices, coffee shops, mobile networks and public clouds.
• Attackers often use compromised devices or rented cloud instances that appear legitimate.
• Traditional username/password/MFA checks do not verify the legitimacy of the device itself.
• Adding a location check/monitoring makes it much harder for an adversary to reuse stolen credentials from an unexpected region.

When you combine device certificates, modern identity federation, and geofencing, you create a zero trust style gateway that only accepts traffic that meets all three criteria:

1. Valid client certificate issued by your private Device Trust CA.
2. Successful authentication with your Identity Provider (IdP).
3. Source IP (or X-Forward-For) belongs to an expected country, city or ASN.

If any of these checks fail, the request is dropped before it reaches downstream services.

The Role of Geofencing in Hardening Access Gateways

Geofencing works by mapping an incoming IP address to a set of attributes – usually:

• Country code (ISO‑3166 two‑letter format).
• City name, coordinates and accuracy radius.
• Autonomous System Number (ASN) which identifies the ISP or network owner.

These mappings are provided by public databases such as MaxMind’s GeoLite2. Because the data is freely available, you can implement geofencing without paying for a commercial service. The key steps are:

1. Download and regularly update the GeoIP database.
2. Load the database into your reverse proxy (Nginx in this example).
3. Define rules that allow or deny traffic based on the mapped attributes.
4. (Optional) Combine those rules with device certificate validation and IdP User attributes .

Getting Started with GeoIP Data Sources

MaxMind offers three primary free databases:

• GeoLite2‑Country – maps IP to country code.
• GeoLite2‑ASN – maps IP to ASN number and organization name.
• GeoLite2-City– maps IP to City name as well as latitude, longitude, and accuracy radius.

Note: There are other free and paid providers of MaxMind (.mmdb) geolocation databases, which also should integrate into the same tooling without issue. Some great options are ipinfo lite, iplocate free, and ip2location lite.

You can obtain them by creating a free MaxMind account, accepting the license, and downloading the .mmdb files. To keep the data fresh you should schedule regular updates (MaxMind releases new versions weekly). The open source tool geoipupdate automates this process:

# Install geoipupdate on Debian/Ubuntu
apt-get update
apt-get install -y geoipupdate

# Create /etc/GeoIP.conf with your account details
cat <<EOF | sudo tee /etc/GeoIP.conf
AccountID YOUR_ACCOUNT_ID
LicenseKey YOUR_LICENSE_KEY
EditionIDs GeoLite2-Country GeoLite2-City GeoLite2-ASN
EOF

# Run the update immediately and enable a daily cron job
sudo geoipupdate

The resulting files are typically stored in /var/lib/GeoIP/ as GeoLite2-Country.mmdb and GeoLite2-ASN.mmdb. Adjust the paths in your Nginx configuration accordingly.

Installing and Configuring ngx_http_geoip2_module

The ngx_http_geoip2_module is a third‑party module that provides fast lookups of GeoIP data inside Nginx. It works with both the open source and commercial versions of Nginx, but for most Linux distributions you will need to compile it as a dynamic module.

#Install Build Prerequisites
apt-get install -y build-essential libpcre3-dev zlib1g-dev libssl-dev libmaxminddb-dev  nginx wget git vim

#Download Nginx Source and the GeoIP2 Module
NGINX_VERSION=$(nginx -v 2>&1 | cut -d'/' -f2| cut -d' ' -f1)
wget http://nginx.org/download/nginx-${NGINX_VERSION}.tar.gz
tar xzf nginx-${NGINX_VERSION}.tar.gz
git clone https://github.com/leev/ngx_http_geoip2_module.git

#Compile the Module as a Dynamic Loadable Object
cd nginx-${NGINX_VERSION}
./configure --with-compat --add-dynamic-module=../ngx_http_geoip2_module
make modules
cp objs/ngx_http_geoip2_module.so /usr/share/nginx/modules/
echo "load_module modules/ngx_http_geoip2_module.so;" > /etc/nginx/modules-available/mod-http-geoip2.conf
ln -s /etc/nginx/modules-available/mod-http-geoip2.conf /etc/nginx/modules-enabled/60-mod-http-geoip2.conf


#Enable and configure the Module by adding the following to the http section
vim /etc/nginx/nginx.conf

'''
geoip2 /var/lib/GeoIP/GeoLite2-Country.mmdb {
    auto_reload 60m;
    $geoip2_metadata_country_build metadata build_epoch;
    $geoip2_country_code country iso_code;
    $geoip2_country_name country names en;
}

geoip2 /var/lib/GeoIP/GeoLite2-City.mmdb {
    auto_reload 60m;
    $geoip2_metadata_city_build metadata build_epoch;
    $geoip2_city_name city names en;
}

fastcgi_param COUNTRY_CODE $geoip2_country_code;
fastcgi_param COUNTRY_NAME $geoip2_country_name;
fastcgi_param CITY_NAME    $geoip2_city_name;
'''

Now you can use the GeoIP2 country or city variables or create custom directives inside your server blocks.

Blocking Traffic by Country with Nginx GeoIP2

A simple config that only allows traffic from the United States and Canada might look like this:

http {

    map $geoip2_country_code $allowed_country {
        default no;
        US      yes;
        CA      yes;
    }

    server {
        listen 443 ssl;
        server_name gateway.example.com;

        # TLS configuration omitted for brevity

        if ($allowed_country = no) {
            return 403;
        }

        location / {
            proxy_pass http://backend;
        }
    }
}

This configuration uses the $geoip2_country_code variable loaded from the geoip2 via the main nginx config. The map block creates a boolean variable $allowed_country that is later used in an if statement to reject disallowed traffic with HTTP 403.

ASN Based Geofence on an Nginx Reverse Proxy

Blocking by ASN provides finer granularity than country alone, especially when you want to restrict access to corporate ISP ranges or known cloud providers. Below is a more advanced configuration that:

• Allows only devices originating from your corporate ASN (e.g., AS12345) or a trusted cloud provider (AS67890).
• Requires a valid client certificate signed by your internal CA.
• Sends the authenticated request to an internal API gateway.

http {
    # Load both country and ASN databases
    geoip2 /var/lib/GeoIP/GeoLite2-ASN.mmdb {
        auto_reload 5m;
        $geoip2_asn_number asn asn;
        $geoip2_asn_org asn organization;
    }

    # Define the list of permitted ASNs
    map $geoip2_asn_number $asn_allowed {
        default          no;
        12345            yes;   # Corporate ISP
        67890            yes;   # Trusted Cloud Provider
    }

    server {
        listen 443 ssl;
        server_name api-gateway.example.com;

        # TLS configuration (certificate, key) omitted for brevity

        # Enforce mutual TLS – reject if no cert or invalid cert
        ssl_verify_client on;
        ssl_client_certificate /etc/nginx/certs/ca.crt; # Your CA Chain

        # If client certificate verification fails, Nginx returns 400 automatically.
        # Add an explicit check for ASN after TLS handshake:
        if ($asn_allowed = no) {
            return 403;
        }

        location / {
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Client-Cert $ssl_client_cert;
            proxy_set_header X-Client-DN  $ssl_client_s_dn
            proxy_pass http://internal-app;
        }
    }
}

Explanation of key parts

• $geoip2_asn_number is populated by the GeoIP2 lookup; the map block translates the ASN into a simple yes/no flag.
• The if ($asn_allowed = no) clause blocks any request that does not originate from an allowed ASN, even if the client certificate is valid.

You can extend this pattern to include city-level checks ($geoip2_city_name) or combine multiple criteria with logical operators.

Integrating GeoIP Policy with Authentik IDP

Authentik is a modern open source identity provider that supports OIDC, SAML and LDAP. It can enforce additional policies during the authentication flow, such as requiring a specific claim that matches your geofence rules.

Enable the GeoIP Policy within Authentik

Since Authentik version 2022.12 GeoIP is baked in and only requires mmdb files provided during startup for policies to be enabled.

• Upload the same GeoLite2-City.mmdb & GeoLite2-ASN.mmdb files used for Nginx.
• Provide the GeoIP (city mmdb) and ASN (ASN mmdb) file paths as env variables during startup
• Setup schedule to update the files or configure geoipupdate plugin/container with your license key.

Now every authentication request will have an ASN value attached, which can be referenced in policies.

Create a GeoIP Polices in Authentik

In the Authentik admin UI:

1. Navigate to Customizations → Policies.
2. Add a new GeoIP Policy named “GeoIP Default”.
3. Configure the default Distance and Static settings based on your needs

Distance Settings:

• Maximum distance – The maximum distance allowed in Kilometers between logins
• Distance tolerance – The allowable difference to account for data accuracy
• Historical Login Count – The number of past logins to account for when evaluating
• Check impossible travel – Whether to check logins/sessions for impossible travel >1k

Static Settings

• Allowed ASNs – Comma separated list of all of the ASNs allowed to for the given policy
• Allowed Countries – List of countries the policy allows connections from

(Optional) Create a Custom Policy in Authentik

In the Authentik admin UI:

1. Navigate to Customizations → Policies.
2. Add a new Expression Policy named “GeoIP ASN Allowlist”.
3. Use the following Jinja2 expression (replace the ASNs with your allowed values):

{% set allowed_asns = [12345, 67890] %}
{{ context["asn"]["asn"] in allowed_asns and context["geoip"]["continent"] == "NA" }}

The context[“asn”] attribute is automatically populated by Authentik when the GeoIP ASN database and context[“geoip”] is provided by GeoIP City database. Both are used in conjunction here to required connections from an approved ASN network and from North America.

Attach the Policy to Your OIDC Application

1. Open Applications → Your API Gateway.
2. Under Policy Binding, add the “GeoIP Default” policy.
3. (Optional) Under Policy Binding, add the “GeoIP ASN Allowlist” policy.
4. Save changes.

When a user authenticates via Authentik, the flow will evaluate the policy. If the source IP belongs to an unauthorized ASN, authentication fails and no token is issued. This adds a second line of defense: even if an attacker obtains valid client certificates, they cannot get a JWT unless they connected from an allowed network.

Enforce Token Claims at Nginx

You can configure Nginx to validate the JWT issued by Authentik and also verify that it contains the expected ip_asn claim. The ngx_http_auth_jwt_module (available in the open source version) can be used:

http {
    # Load GeoIP2 as before

    server {
        listen 443 ssl;
        server_name api-gateway.example.com;

        # TLS settings omitted

        auth_jwt "Protected API";
        auth_jwt_key_file /etc/nginx/jwt-public.key;   # Authentik public key
        auth_jwt_claim_set $jwt_asn ip_asn;

        # Reject if JWT claim does not match allowed ASN list
        map $jwt_asn $jwt_asn_allowed {
            default no;
            12345   yes;
            67890   yes;
        }

        if ($jwt_asn_allowed = no) {
            return 403;
        }

        location / {
            proxy_pass http://internal-api;
        }
    }
}

The flow now looks like this:

1. TLS handshake verifies client certificate.
2. Nginx extracts the source IP and performs GeoIP ASN lookup.
3. The request is redirected to Authentik for OIDC authentication.
4. Authentik checks the “GeoIP ASN Allowlist” policy; if it passes, a JWT containing ip_asn is returned.
5. Nginx validates the JWT and ensures the claim matches the allowed list before proxying to the backend.

This combination of device trust certificates, geofence enforcement and IdP policies creates a robust zero‑trust perimeter around your sensitive services.

Best Practices for Maintaining Geofencing Rules

• Regularly update GeoIP databases – use geoipupdate with cron or systemd timers.
• Keep an audit log of denied requests – configure Nginx error logs to capture $remote_addr, $geo_country_code, $geo_asn_number and the reason for denial.
• Use a allowlist rather than a blocklist – allow only known good ASNs/countries; attackers can easily spoof or route through VPNs that belong to allowed regions.
• Combine with rate limiting – even legitimate IP ranges may be abused; use limit_req_zone and limit_conn_zone.
• Test changes in a staging environment – a mis‑configured ASN map could lock out all users out of an application, including administrators.
• Monitor for anomalies – sudden spikes of traffic from an unexpected ASN can indicate compromised credentials.

Access Flow Diagram

Below is flowchart that visualizes the hardened access methodology. Only devices presenting a valid client Device Trust certificate and originating from an allowed location/ASN are permitted to obtain an authentication token and reach the protected service.

The diagram highlights three independent checks:

• TLS client certificate – ensures the device holds a trusted private key.
• GeoIP ASN validation at Nginx – blocks traffic from unknown networks before any authentication attempt.
• Authentik policy enforcement and JWT claim verification – guarantees that the token itself reflects an allowed source network and travel distance is within tolerance.

Only when all three conditions succeed does the request reach the backend service.

Monitoring and Auditing Geofence Enforcement

A hardened gateway is only as good as its visibility. Implementing robust logging and alerting helps you detect misconfigurations or active attacks.

Nginx Log Format Extension

Add a custom log format that captures GeoIP variables:

http {
    log_format geo_combined '$remote_addr - $remote_user [$time_local] '
                            '"$request" $status $body_bytes_sent '
                            '"$http_referer" "$http_user_agent" '
                            'asn=$geoip2_asn_number country=$geoip2_country_code';

    access_log /var/log/nginx/access_geo.log geo_combined;
}

Centralized Log Collection

• Ship logs to Elasticsearch, Splunk or Loki.
• Create dashboards that filter on status=403 and group by $geoip2_asn_number.
• Set alerts for spikes in denied traffic from a single ASN.

Scaling Geofence Enforcement Across Multiple Gateways

In large environments you may have dozens of ingress controllers. To keep policies consistent:

• Store the allowed ASN list in a central source (e.g., Consul KV, etcd, or a ConfigMap).
• Use a templating engine like envsubst or Helm to generate Nginx configs on each node.
• Automate database updates with a CI/CD pipeline that pulls the latest MaxMind files and pushes them to all pods.

By treating the geofence policy as code you can version it, review changes via pull requests, and roll back quickly if an error blocks legitimate traffic.

Conclusion

Geofencing is a powerful yet straightforward technique for hardening access gateways with geofencing. By leveraging free GeoIP data from MaxMind, the ngx_http_geoip2_module in Nginx, and modern identity providers such as Authentik, you can enforce policies that require:

• A trusted device certificate.
• An allowed source network identified by ASN.
• Successful authentication with a policy‑aware IdP.

The layered approach dramatically reduces the attack surface for privileged services, makes credential theft less useful, and gives security teams clear visibility into who is trying to connect from where. Combined with automated updates, logging, and containerized deployment, geofence enforcement can scale across hybrid cloud environments without adding significant operational overhead.

Start by downloading the GeoLite2 databases, compile the GeoIP2 module for your Nginx instances, define a allowlist of ASNs that correspond to your corporate trust network and approved cloud providers, and integrate the policy into your IdP. From there monitor the logs, tune the allowlist as your network evolves, and you’ll have a robust zero‑trust perimeter protecting your most sensitive workloads.

Remember: Device trust plus geofencing equals stronger security – and with the tools described in this post you can implement it today on Linux, cloud, and container platforms.