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

Type	Best For	IP Stability	Example
Server	Production servers, office networks, cloud subnets	Static (unchanging)	AWS EC2 with Elastic IP, office `192.168.1.0/24`
User	Developer machines, QA testers	Dynamic (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 without also locking down the server identity

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

Feature	Server	User
IP Format	Single IP or CIDR range	Single IP or CIDR range
Example IP	`52.123.45.67` or `192.168.1.0/24`	`203.45.67.89`
Stability	Permanent	May change
Use Case	Production servers, office networks	Developer laptops, QA testers
Trust Level	High	Medium
Environment	Production, Staging	Dev/Staging
Maintenance	Low	Medium (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:

Provision Elastic IP from cloud provider
Assign to instance
Edit client in KnoxCall
Change type to Server
Update IP to Elastic IP
Update description
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

Situation	Type	Example
Production server with Elastic IP	Server	`52.123.45.67`
Developer’s laptop at home	User	`203.45.67.89`
Office Wi-Fi network	Server	`192.168.1.0/24`
Staging server on cloud	Server	`54.200.11.22`
QA team member	User	`180.123.45.67`
Corporate VPN	Server	`10.8.0.0/16`
Partner’s webhook server	Server	`100.25.30.45`
Temporary contractor	User	`192.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.

​Client Types Explained

​The Two Types

​Server Type

​Overview

​Characteristics

​When to Use

​Examples

​AWS EC2 with Elastic IP

​DigitalOcean Droplet

​Partner Integration

​Best Practices

​User Type

​Overview

​Characteristics

​When to Use

​Examples

​Developer Laptop

​QA Team Member

​Remote Contractor

​Dynamic IP Challenges

​Best Practices

​Using CIDR Ranges

​Examples with CIDR

​Office Network

​Corporate VPN

​Cloud Provider Subnet

​Common CIDR Ranges

​CIDR Best Practices

​Comparison Table

​Choosing the Right Type

​Decision Tree

​Examples

​Security Considerations

​Trust Levels

​Recommendations by Environment

​Migration Between Types

​User → Server (When Getting Static IP)

​Network → Multiple Servers

​Real-World Patterns

​Pattern 1: Startup (Small Team)

​Pattern 2: Enterprise (Large Team)

​Pattern 3: Agency/Consultancy

​Quick Reference

​Next Steps

What are Clients?

Managing Clients

CIDR Notation

IP Issues

Client Types Explained

The Two Types

Server Type

Overview

Characteristics

When to Use

Examples

AWS EC2 with Elastic IP

DigitalOcean Droplet

Partner Integration

Best Practices

User Type

Overview

Characteristics

When to Use

Examples

Developer Laptop

QA Team Member

Remote Contractor

Dynamic IP Challenges

Best Practices

Using CIDR Ranges

Examples with CIDR

Office Network

Corporate VPN

Cloud Provider Subnet

Common CIDR Ranges

CIDR Best Practices

Comparison Table

Choosing the Right Type

Decision Tree

Examples

Security Considerations

Trust Levels

Recommendations by Environment

Migration Between Types

User → Server (When Getting Static IP)

Network → Multiple Servers

Real-World Patterns

Pattern 1: Startup (Small Team)

Pattern 2: Enterprise (Large Team)

Pattern 3: Agency/Consultancy

Quick Reference

Next Steps