Skip to main content

​
Client Types Explained

KnoxCall supports three types of clients, each optimized for different use cases. This guide helps you choose the right type.

​
The Three Types

TypeIconBest ForIP StabilityExample
Server🖥️Production serversStatic (unchanging)AWS EC2 with Elastic IP
User👤Developer machinesDynamic (may change)Laptop on home Wi-Fi
Network🌐IP rangesMultiple IPsOffice network 192.168.1.0/24

​
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

​
Network Type

​
Overview

Network clients represent ranges of IP addresses using CIDR notation, allowing multiple IPs to access routes.

​
Characteristics

✅ IP range - Multiple addresses (CIDR) ✅ Network segment - Group of devices ✅ Convenient - Authorize many IPs at once ✅ Flexible - Covers subnets

​
When to Use

Use Network type when:
  • Office Wi-Fi network
  • Corporate VPN range
  • Data center subnet
  • Cloud provider IP range
  • Partner company network
  • Multiple related servers

​
Examples

​
Office Network

Name: office-wifi-main
Type: Network
IP: 192.168.1.0/24
Description: Main office Wi-Fi - all floors, ~200 employees
Why Network type:
  • Covers entire office (192.168.1.1 to 192.168.1.254)
  • Multiple people on same network
  • CIDR notation needed
IP coverage: 256 addresses
  • 192.168.1.0 (network address)
  • 192.168.1.1 to 192.168.1.254 (usable)
  • 192.168.1.255 (broadcast address)

​
Corporate VPN

Name: company-vpn
Type: Network
IP: 10.8.0.0/16
Description: Corporate VPN - all remote employees
Why Network type:
  • VPN assigns IPs in 10.8.x.x range
  • Many employees connect
  • CIDR range needed
IP coverage: 65,536 addresses
  • 10.8.0.0 to 10.8.255.255

​
Cloud Provider Subnet

Name: aws-us-east-subnet
Type: Network
IP: 172.31.0.0/20
Description: AWS VPC subnet for microservices
Why Network type:
  • Multiple EC2 instances in subnet
  • Dynamic instance IPs within range
  • Subnet-level authorization
IP coverage: 4,096 addresses
  • 172.31.0.0 to 172.31.15.255

​
Partner Network

Name: partner-acme-network
Type: Network
IP: 203.14.0.0/16
Description: ACME Corp office network - all locations
Why Network type:
  • Partner has multiple offices
  • Many servers in their network
  • Easier than individual IPs

​
CIDR Notation

Network type requires CIDR notation: IP/prefix Common CIDR ranges:
  • /32 - 1 IP (don’t use Network type, use Server instead)
  • /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)
Examples: 
192.168.1.0/24   → 192.168.1.0 to 192.168.1.255
10.0.0.0/16      → 10.0.0.0 to 10.0.255.255
172.31.0.0/20    → 172.31.0.0 to 172.31.15.255
See CIDR Notation Guide for details.

​
Best Practices

✅ Do:
  • Use smallest range that covers your needs
  • Document what network represents
  • Be specific about location/purpose
  • Audit periodically (remove if unused)
  • Use for related devices only
❌ Don’t:
  • Use 0.0.0.0/0 (allows entire internet!)
  • Use overly broad ranges unnecessarily
  • Mix unrelated networks in one client
  • Forget to document what’s in the range

​
Comparison Table

FeatureServerUserNetwork
IP FormatSingle static IPSingle dynamic IPCIDR range
Example IP52.123.45.67203.45.67.89192.168.1.0/24
StabilityPermanentMay changePermanent range
Quantity1 address1 addressMany addresses
Use CaseProduction serversDeveloper laptopsOffice networks
Trust LevelHighMediumMedium
EnvironmentProductionDev/StagingDev/Staging/Prod
MaintenanceLowMedium (IP updates)Low

​
Choosing the Right Type

​
Decision Tree

Do you have multiple IPs to authorize?
├─ YES → Use Network (CIDR range)
└─ NO → Does the IP change?
    ├─ YES → Use User (dynamic IP)
    └─ NO → Use Server (static IP)

​
Examples

Scenario: AWS EC2 instance
  • Single IP? ✅ Yes
  • IP changes? ❌ No (Elastic IP)
  • → Server type
Scenario: Developer’s laptop
  • Single IP? ✅ Yes
  • IP changes? ✅ Yes (home Wi-Fi)
  • → User type
Scenario: Office with 50 employees
  • Single IP? ❌ No (50+ devices)
  • → Network type (e.g., 192.168.1.0/24)
Scenario: VPN with 100 users
  • Single IP? ❌ No (100 connections)
  • → Network type (e.g., 10.8.0.0/16)

​
Security Considerations

​
Trust Levels

Server (Highest Trust):
  • ✅ Production traffic allowed
  • ✅ Access to sensitive data
  • ✅ Critical operations
User (Medium Trust):
  • ⚠️ Development/staging only
  • ⚠️ Limited permissions
  • ⚠️ Regular audits
Network (Variable Trust):
  • ⚠️ Depends on what’s in range
  • ⚠️ More IPs = higher risk
  • ⚠️ Audit membership

​
Recommendations by Environment

Production:
  • ✅ Server type only
  • ❌ No User types
  • ⚠️ Network type only for trusted corporate networks
Staging:
  • ✅ Server type for staging servers
  • ✅ User type for QA team
  • ✅ Network type for office
Development:
  • ✅ All 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: Network
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 (Network type):
- 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:
- Network: staging-subnet (10.1.0.0/24)
- Network: office-network (192.168.0.0/16)

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

​
Pattern 3: Agency/Consultancy

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

Internal:
- Network: 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 networkNetwork192.168.1.0/24
Staging server on cloudServer54.200.11.22
QA team memberUser180.123.45.67
Corporate VPNNetwork10.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.