Skip to main content

​
Client Types Explained

KnoxCall supports two types of clients, each optimized for different use cases. Both types support single IPs and CIDR ranges. This guide helps you choose the right type.

​
The Two Types

TypeBest ForIP StabilityExample
ServerProduction servers, office networks, cloud subnetsStatic (unchanging)AWS EC2 with Elastic IP, office 192.168.1.0/24
UserDeveloper machines, QA testersDynamic (may change)Laptop on home Wi-Fi

​
Server Type

​
Overview

Server clients represent production infrastructure with static IP addresses that never (or rarely) change.

​
Characteristics

✅ Static IP address - IP doesn’t change ✅ Production-ready - Designed for reliability ✅ Single IP - One specific address ✅ High trust - Critical infrastructure

​
When to Use

Use Server type when:
  • Production API servers
  • Staging servers
  • Database servers
  • Backend services with static IPs
  • Cloud instances with Elastic IPs
  • VPS with dedicated IPs
  • Partner webhook servers

​
Examples

​
AWS EC2 with Elastic IP

Name: prod-api-server-1
Type: Server
IP: 52.123.45.67
Description: Main production API server in AWS us-east-1
Why Server type:
  • Elastic IP is static (never changes unless you release it)
  • Production traffic
  • Critical infrastructure

​
DigitalOcean Droplet

Name: staging-backend
Type: Server
IP: 159.65.123.45
Description: Staging environment backend on DigitalOcean
Why Server type:
  • Droplet has static IP
  • Staging environment (important but not production)

​
Partner Integration

Name: partner-acme-webhook
Type: Server
IP: 100.25.30.45
Description: ACME Corp webhook callback server
Why Server type:
  • External partner’s server
  • Fixed IP address
  • Business-critical integration

​
Best Practices

✅ Do:
  • Always use for production
  • Document server purpose in description
  • Use meaningful names (prod-api-1 not server1)
  • Track in inventory (spreadsheet/wiki)
  • Regular security audits
❌ Don’t:
  • Use for developer laptops (use User type)
  • Use for dynamic IPs (IP will change, causing issues)
  • Use for IP ranges (use Network type)

​
User Type

​
Overview

User clients represent individual people or devices with potentially dynamic IP addresses.

​
Characteristics

✅ Dynamic IP - May change occasionally ✅ Individual person/device - Not infrastructure ✅ Development-focused - Testing, debugging ✅ Lower trust - Temporary access

​
When to Use

Use User type when:
  • Developer laptops
  • Home office machines
  • QA team computers
  • Temporary contractor access
  • Mobile devices (rare)
  • Any IP that might change

​
Examples

​
Developer Laptop

Name: john-dev-macbook
Type: User
IP: 203.45.67.89
Description: John's MacBook Pro for local development
Why User type:
  • Home Wi-Fi IP changes occasionally
  • Individual developer
  • Development/testing only

​
QA Team Member

Name: qa-alice-laptop
Type: User
IP: 180.123.45.67
Description: Alice (QA) - testing environment access
Why User type:
  • Office IP might change
  • Individual tester
  • Non-production use

​
Remote Contractor

Name: contractor-bob-temp
Type: User
IP: 192.5.8.100
Description: Bob (contractor) - temporary access for Q1 2025
Why User type:
  • Temporary access
  • Individual person
  • Dynamic IP likely

​
Dynamic IP Challenges

Problem: Home/office internet usually has dynamic IPs that change. When IPs change:
  • Router restarts
  • ISP lease expires (every 24-72 hours typically)
  • VPN connects/disconnects
  • Moving locations
Solutions: Option 1: Update IP when it changes 
# Check current IP
curl https://api.ipify.org

# Update client in KnoxCall UI
# Resources → Clients → Edit → Update IP
Option 2: Use API key authentication
  • Create API key with “Allow any IP”
  • Use key in requests instead
  • No IP whitelisting needed
Option 3: Use VPN with static IP
  • Connect to VPN with static egress IP
  • Whitelist VPN IP
  • Always connect through VPN

​
Best Practices

✅ Do:
  • Include person’s name in client name
  • Update description with contact info
  • Remove when person leaves company
  • Use “Allow any IP” API keys for dev (easier)
  • Assign only to dev/staging environments
❌ Don’t:
  • Use for production servers
  • Give production access to User clients
  • Forget to remove when contractor leaves
  • Use generic names like user1

​
Using CIDR Ranges

Both Server and User types support CIDR notation for authorizing IP ranges. This is useful for office networks, VPNs, and cloud subnets.

​
Examples with CIDR

​
Office Network

Name: office-wifi-main
Type: Server
IP: 192.168.1.0/24
Description: Main office Wi-Fi - all floors, ~200 employees
Covers 256 addresses: 192.168.1.0 to 192.168.1.255

​
Corporate VPN

Name: company-vpn
Type: Server
IP: 10.8.0.0/16
Description: Corporate VPN - all remote employees
Covers 65,536 addresses: 10.8.0.0 to 10.8.255.255

​
Cloud Provider Subnet

Name: aws-us-east-subnet
Type: Server
IP: 172.31.0.0/20
Description: AWS VPC subnet for microservices
Covers 4,096 addresses: 172.31.0.0 to 172.31.15.255

​
Common CIDR Ranges

  • /32 - 1 IP (just enter the IP without /32)
  • /24 - 256 IPs (e.g., 192.168.1.0/24)
  • /16 - 65,536 IPs (e.g., 10.0.0.0/16)
  • /8 - 16,777,216 IPs (very large, rare)
See CIDR Notation Guide for details.

​
CIDR Best Practices

✅ Do:
  • Use smallest range that covers your needs
  • Document what network the range represents
  • Audit periodically (remove if unused)
❌ Don’t:
  • Use 0.0.0.0/0 (allows entire internet!)
  • Use overly broad ranges unnecessarily

​
Comparison Table

FeatureServerUser
IP FormatSingle IP or CIDR rangeSingle IP or CIDR range
Example IP52.123.45.67 or 192.168.1.0/24203.45.67.89
StabilityPermanentMay change
Use CaseProduction servers, office networksDeveloper laptops, QA testers
Trust LevelHighMedium
EnvironmentProduction, StagingDev/Staging
MaintenanceLowMedium (IP updates)

​
Choosing the Right Type

​
Decision Tree

Is this infrastructure (servers, networks, VPNs)?
├─ YES → Use Server type
└─ NO → Is this a person (developer, tester)?
    └─ YES → Use User type

​
Examples

Scenario: AWS EC2 instance
  • Infrastructure? ✅ Yes (static Elastic IP)
  • → Server type
Scenario: Developer’s laptop
  • Infrastructure? ❌ No (person’s device)
  • → User type
Scenario: Office with 50 employees
  • Infrastructure? ✅ Yes (network)
  • → Server type with CIDR range (e.g., 192.168.1.0/24)
Scenario: VPN with 100 users
  • Infrastructure? ✅ Yes (VPN network)
  • → Server type with CIDR range (e.g., 10.8.0.0/16)

​
Security Considerations

​
Trust Levels

Server (Highest Trust):
  • ✅ Production traffic allowed
  • ✅ Access to sensitive data
  • ✅ Critical operations
  • ⚠️ CIDR ranges increase exposure — use the smallest range needed
User (Medium Trust):
  • ⚠️ Development/staging only
  • ⚠️ Limited permissions
  • ⚠️ Regular audits

​
Recommendations by Environment

Production:
  • ✅ Server type only
  • ❌ No User types
  • ⚠️ CIDR ranges only for trusted corporate networks
Staging:
  • ✅ Server type for staging servers
  • ✅ User type for QA team
Development:
  • ✅ Both types acceptable
  • ✅ User type most common
  • ✅ API keys easier than IP whitelisting

​
Migration Between Types

​
User → Server (When Getting Static IP)

Before: 
Name: dev-server
Type: User
IP: 203.45.67.89 (dynamic)
After getting Elastic IP: 
Name: prod-api-server
Type: Server
IP: 52.123.45.67 (Elastic IP - static)
Steps:
  1. Provision Elastic IP from cloud provider
  2. Assign to instance
  3. Edit client in KnoxCall
  4. Change type to Server
  5. Update IP to Elastic IP
  6. Update description
  7. Save

​
Network → Multiple Servers

Before (inefficient): 
Name: cloud-subnet
Type: Server
IP: 172.31.0.0/20
Description: All instances (10 production, 50 dev)
After (more secure): 
Production servers (Server type):
- prod-api-1: 172.31.1.10
- prod-api-2: 172.31.1.11
- prod-db-1: 172.31.1.20

Development network (Server type with CIDR):
- dev-subnet: 172.31.8.0/22
Benefit: Production servers explicitly listed, dev instances in subnet.

​
Real-World Patterns

​
Pattern 1: Startup (Small Team)

Production:
- Server: prod-api (52.123.45.67)
- Server: prod-db (52.123.45.68)

Development:
- User: john-laptop (dynamic)
- User: jane-laptop (dynamic)
- User: bob-laptop (dynamic)
Why: Simple setup, few people, API keys easier than IP management for devs.

​
Pattern 2: Enterprise (Large Team)

Production:
- Server: prod-api-1 through prod-api-10 (specific IPs)
- Server: prod-worker-1 through prod-worker-5

Staging:
- Server: staging-subnet (10.1.0.0/24)
- Server: office-network (192.168.0.0/16)

Development:
- Server: dev-vpn (10.8.0.0/16)
Why: Granular production control, convenient staging/dev access.

​
Pattern 3: Agency/Consultancy

Clients:
- Server: client-acme-network (203.14.0.0/24)
- Server: client-widgets-vpn (10.9.0.0/16)
- Server: client-globex-server (100.25.30.45)

Internal:
- Server: office-wifi (192.168.1.0/24)
- User: contractor-alice (temporary)
- User: contractor-bob (temporary)
Why: Each client gets appropriate access, contractors temporary User type.

​
Quick Reference

SituationTypeExample
Production server with Elastic IPServer52.123.45.67
Developer’s laptop at homeUser203.45.67.89
Office Wi-Fi networkServer192.168.1.0/24
Staging server on cloudServer54.200.11.22
QA team memberUser180.123.45.67
Corporate VPNServer10.8.0.0/16
Partner’s webhook serverServer100.25.30.45
Temporary contractorUser192.5.8.100

​
Next Steps

What are Clients?

Client basics and concepts

Managing Clients

Create, edit, assign clients

CIDR Notation

Understanding IP ranges (coming soon)

IP Issues

Troubleshoot IP problems
Pro Tip: For production, always use Server type with static IPs. For development, use User type or API keys with “Allow any IP” to avoid constant IP updates.