IP Allowlisting & Network Security

A valid mTLS certificate is necessary but not sufficient. Every request also passes through two further network-layer checks: an IP allowlist, and a forward-confirmed reverse DNS (FCrDNS) check against your certificate's domains. All three checks — certificate, IP allowlist, and FCrDNS — must pass independently.

The three-layer model

sequenceDiagram
    participant Client
    participant TLS as TLS layer
    participant WAF as Network / WAF layer
    participant API as Axys API

    Client->>TLS: TLS handshake with client certificate
    TLS->>TLS: Validate certificate (issuer, validity, not revoked)
    alt Certificate invalid
        TLS-->>Client: Connection refused
    end
    TLS->>WAF: Handshake succeeded
    WAF->>WAF: Check 1 — Is the calling IP allowlisted<br/>for this Tenant/Program?
    WAF->>WAF: Check 2 — FCrDNS: do the certificate's<br/>CN/SAN domains resolve to this IP,<br/>and does this IP resolve back to them?
    alt Either check fails
        WAF-->>Client: 403 "No Authorised IPs configured"
    end
    WAF->>API: Forward request
    API->>API: Validate X-API-Key, resolve Program scope
    API-->>Client: Response

❗️

Both Check 1 and Check 2 above produce the same error message — 403 "No Authorised IPs configured". A passing mTLS handshake combined with this error does not, by itself, tell you which check failed. Work through both below.

Check 1: IP allowlisting

Your calling IP address(es) must be registered against your Tenant/Program before requests from them are accepted.

📘

Self-service IP registration is managed via an Account Management endpoint. IP allowlisting is configured during onboarding via your Axys onboarding contact — see Onboarding Overview & Checklist.

Check 2: Forward-confirmed reverse DNS (FCrDNS)

FCrDNS verifies that you genuinely control both the domain(s) in your certificate and the IP address(es) you're calling from, by checking DNS in both directions:

1. Forward (A record): the domain(s) in your certificate's CN/SAN must resolve to your calling IP. For example, if your certificate includes api.acmecards.example and you call from 203.0.113.10, then api.acmecards.example must have an A record pointing to 203.0.113.10.
2. Reverse (PTR record): your calling IP must have a PTR record that resolves back to one of the domains in your certificate. For 203.0.113.10, the reverse DNS lookup should return api.acmecards.example (or another domain listed in your certificate's SAN).

Both directions must be consistent — hence "forward-confirmed" reverse DNS. You can check both yourself:

# Forward: does the domain resolve to your IP?
dig +short api.acmecards.example

# Reverse: does your IP resolve back to the domain?
dig +short -x 203.0.113.10

🚧

Cloud provider IPs often need an explicit PTR record request. If you're calling from a cloud provider's IP range (e.g. an AWS Elastic IP), the provider typically owns the reverse DNS zone for that IP and won't set a custom PTR record automatically — you'll usually need to request it through your cloud provider's support process. Until that PTR record is set and propagated, Check 2 will fail even with a perfectly correct certificate and a correctly allowlisted IP.

NAT gateways and multi-AZ deployments

If your servers run inside a VPC behind a NAT gateway, your calling IP (as seen by Axys) is the NAT gateway's IP — typically an Elastic IP (EIP) — not your instances' private IP addresses.

• Allowlist the NAT gateway's EIP(s), not instance-level addresses.
• If you run NAT gateways across multiple Availability Zones for redundancy, each AZ's EIP is a distinct calling IP and needs its own allowlist entry, A record coverage, and PTR record.
• Alternatively, consolidate outbound traffic to the Axys API through a single NAT gateway / EIP to minimize the number of IPs you need to manage — weigh this against your own availability requirements.

Troubleshooting the 403 "No Authorised IPs configured" error

What's next

• mTLS Certificates & CSR
• Security Compliance & Data Protection
• Errors & Status Codes