Features | Pricing | Documentation | Contact | Blog

Client Restrictions

Client Restrictions in Proxylity are the rules that determine which sources of IP traffic should be allowed by your Listener(s). They act as a firewall between the internet at large and your Destinations, and are crucial for preventing abuse and unauthorized access to your services.

Choose the restriction method that best fits your use case:

Proxylity UDP Gateway supports the following types of Client Restrictions:

Choosing the Right Method

Each restriction method has its strengths. Here's a quick comparison to help you choose:

Method Best For Complexity Flexibility
CIDR Blocks Static networks, simple setups Low Low
Domain Names Dynamic IPs with stable hostnames Medium Medium
CPF Records Complex policies, team delegation High High

Pro tip: You can combine multiple restriction methods. Proxylity will allow traffic if any of the configured restrictions permit it.

Allowed IP Addresses and CIDRs

CIDR (Classless Inter-Domain Routing) restrictions allow you to specify individual IP addresses or entire ranges using CIDR notation. This is the most straightforward method for controlling access when you know the specific IP addresses or ranges that should be allowed.

When to use:

Examples:

Allowed Domain Names

Domain-based restrictions allow you to permit traffic based on reverse DNS lookups rather than static IP addresses. When a request arrives, Proxylity performs a reverse lookup to determine the hostname associated with the source IP, then checks if that domain is on your allowed list.

When to use:

Important considerations:

Client Policy Records (CPF)

Client Policy Framework (CPF) is the most flexible and powerful restriction method. Similar to how SPF (Sender Policy Framework) works for email, CPF uses DNS TXT records to define which IP addresses are authorized to access your services. This allows you to manage access control through DNS without modifying Proxylity configuration.

When to use CPF:

CPF Record Format

CPF records follow a simple, SPF-like syntax:

v=cpf1 [mechanism1] [mechanism2] ...

Important syntax notes:

Supported Mechanisms

Mechanism Description Example
ip4 IPv4 address or CIDR block ip4:192.168.1.0/24
ip6 IPv6 address or CIDR block ip6:2001:db8::/32
a Allow IPs that resolve to this domain's A records a:example.com
include Include another domain's CPF policy include:partners.com
exists Allow if DNS A record exists for {ip}.domain exists:allowlist.example.com
all Catch-all (use with qualifiers) -all (deny everything else)

Qualifiers

Each mechanism can be prefixed with a qualifier to specify the action:

Note: The current implementation only distinguishes between Pass (+) and all other qualifiers. Qualifiers ~ (SoftFail) and ? (Neutral) are parsed but treated the same as - (Fail).

Modifiers (Not Currently Implemented)

While the CPF parser can recognize exp and redirect modifiers, these are not currently implemented in the policy evaluation logic. They will be parsed without error but have no effect on access decisions.

Example CPF Records

Basic example - Allow specific IPs and deny all others:

v=cpf1 ip4:203.0.113.0/24 ip4:198.51.100.10 -all

Corporate network with partner inclusion:

v=cpf1 ip4:10.0.0.0/8 include:partners.example.com a:vpn.mycompany.com -all

Dynamic allowlist using exists mechanism:

v=cpf1 exists:approved.mycompany.com -all

This allows any IP if a DNS A record exists for {ip}.approved.mycompany.com

Setting Up CPF Records with AWS Route 53

Here are example AWS CLI commands to create CPF records in Route 53:

1. Create a basic CPF record

aws route53 change-resource-record-sets --hosted-zone-id Z1234567890ABC --change-batch '{
  "Changes": [{
    "Action": "CREATE",
    "ResourceRecordSet": {
      "Name": "myservice.example.com",
      "Type": "TXT",
      "TTL": 300,
      "ResourceRecords": [{
        "Value": "\"v=cpf1 ip4:203.0.113.0/24 ip4:198.51.100.10 -all\""
      }]
    }
  }]
}'

2. Create a CPF record with partner inclusion

aws route53 change-resource-record-sets --hosted-zone-id Z1234567890ABC --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "api.mycompany.com",
      "Type": "TXT",
      "TTL": 300,
      "ResourceRecords": [{
        "Value": "\"v=cpf1 ip4:10.0.0.0/8 include:partners.example.com a:vpn.mycompany.com -all\""
      }]
    }
  }]
}'

3. Update an existing CPF record

aws route53 change-resource-record-sets --hosted-zone-id Z1234567890ABC --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "gateway.example.com",
      "Type": "TXT", 
      "TTL": 300,
      "ResourceRecords": [{
        "Value": "\"v=cpf1 exists:approved.mycompany.com ip4:192.168.0.0/16 -all\""
      }]
    }
  }]
}'

Testing Your CPF Records

You can verify your CPF records are properly configured using standard DNS tools:

# Using dig
dig TXT myservice.example.com

# Using nslookup
nslookup -type=TXT myservice.example.com

# Using PowerShell (Windows)
Resolve-DnsName -Name myservice.example.com -Type TXT

Implementation Notes

Based on the current ClientPolicyLibrary implementation:

Best Practices

Troubleshooting

Common issues and solutions:

Known Limitations: