Use Case Scenarios

Practical guides for common rVPN deployments.

---

Choosing Your Mode

rVPN supports two operating modes:

Use case	Recommended mode
App-specific proxying (browser, individual apps)	SOCKS5
Full device VPN (all traffic)	TUN
Mobile (iOS, Android)	TUN (built-in)
Connecting to a remote network as if on LAN	TUN
Split tunnel: some traffic VPN, some direct	Either with split_tunnel config

Both modes use the same X3DH + Double Ratchet encryption. The difference is how traffic reaches the VPN.

---

Remote Desktop Access

Connect to your work computer from home as if you were on the same office network. Use RDP, VNC, SSH, or any remote access tool without exposing ports to the public internet.

What this solves

• RDP/VNC exposed to the internet is a common attack vector
• Corporate firewalls often block RDP ports
• You want to access your office printer, file shares, and internal tools

Setup

1. Server configuration

The server must be on your office network with TUN mode enabled and NAT configured:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/letsencrypt/live/your-office-server.com/fullchain.pem"
tls_key_file      = "/etc/letsencrypt/live/your-office-server.com/privkey.pem"
identity_key_file = "/etc/rvpn/server_identity.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = true
dhcp_range  = "10.200.0.0/24"

[server.tun]
tun_ip      = "10.200.0.1/24"
dns_servers = ["1.1.1.1", "8.8.8.8"]

2. Client configuration

Route only your office network subnet through the VPN. Do not route all traffic:

server_address    = "wss://your-office-server.com/api/v1/ws"
identity_key_file = "~/.config/rvpn/identity.key"
prekey_bundle     = "~/.config/rvpn/prekey-bundle.json"

[tun]
enabled = true
routes  = ["10.100.0.0/16"]    # Your office network subnet
mtu     = 1420

This routes only traffic destined for 10.100.0.0/16 (your office network) through the VPN. All other traffic (browsing, streaming) uses your normal home connection.

3. Verify connectivity

# Force curl through the TUN interface (tun0 on macOS/Linux, utun# on iOS)
curl --interface tun0 https://ifconfig.me

# Should return an office network IP (your VPN tunnel IP)
# If routing works, regular curl should also work without --interface

# Should reach an office server
ping 10.100.0.50

What works through the tunnel

• RDP: 10.100.0.50:3389
• VNC: 10.100.0.51:5900
• SSH: ssh [email protected]
• SMB file shares: \\10.100.0.53\share
• Internal web apps: http://10.100.0.54:8080

---

Private Network Linking

Connect multiple servers across different locations into one secure private network. All servers and clients appear to be on the same LAN regardless of physical location.

What this solves

• Connecting offices in different cities without leased lines
• Accessing cloud VMs as if they were on the same network
• Running cluster software that requires LAN-level network discovery

Architecture

Office A (10.100.0.0/24)          Cloud Region (10.200.0.0/24)
     |                                     |
  rvpn-server-TUN                    rvpn-server-TUN
  (10.100.0.1)                       (10.200.0.1)
        \                               /
         \                             /
          \---------------------------/
                    |
            rvpn clients get IPs
            in their respective
            DHCP ranges and can
            reach all subnets

Server setup (each location)

Each location runs one rvpn-server in TUN mode. The dhcp_range at each site must be distinct:

Office A server.toml:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/letsencrypt/live/office-a.example.com/fullchain.pem"
tls_key_file      = "/etc/letsencrypt/live/office-a.example.com/privkey.pem"
identity_key_file = "/etc/rvpn/server_identity_office_a.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = true
dhcp_range  = "10.100.0.0/24"

[server.tun]
tun_ip      = "10.100.0.1/24"
dns_servers = ["10.100.0.1"]

Cloud region server.toml:

[server.network]
nat_enabled = true
dhcp_range  = "10.200.0.0/24"

[server.tun]
tun_ip      = "10.200.0.1/24"
dns_servers = ["10.200.0.1"]

Client routing for multi-subnet access

To reach both subnets, the client needs routes for both:

[tun]
enabled = true
routes  = ["10.100.0.0/16", "10.200.0.0/16"]   # Covers both office and cloud subnets
mtu     = 1420

Or if you need full tunnel (all traffic through VPN) simply use routes = ["0.0.0.0/0"].

Private DNS for name resolution

To use hostnames instead of IPs across all locations, configure a private DNS server:

[server.network]
nat_enabled = true
dhcp_range  = "10.100.0.0/24"

[server.tun]
tun_ip      = "10.100.0.1/24"
dns_servers = ["10.100.0.1"]

Point your private DNS at 10.100.0.1. Add host entries:

db01.office.internal    10.100.0.10
db02.office.internal    10.200.0.10

---

Development Environments

Access dev servers, databases, and microservices remotely as if they were running locally. Useful for working from home or travelling.

What this solves

• Dev environments are on a private network and inaccessible from outside
• You need to test webhooks that call localhost
• You want to use local development URLs without changing them

Scenario 1: Access all dev services

Route your entire development network through the VPN:

server_address    = "wss://your-dev-server.com/api/v1/ws"
identity_key_file = "~/.config/rvpn/identity.key"
prekey_bundle     = "~/.config/rvpn/prekey-bundle.json"

[socks5]
listen_address = "127.0.0.1:1080"

[dns_proxy]
enabled        = true
listen_address = "127.0.0.1:53"

Configure your system DNS to 127.0.0.1:53. Now dev.internalcompany.com resolves correctly and all dev traffic goes through the VPN.

Scenario 2: Access specific dev services only

Use TUN mode with specific routes to avoid slowing down your entire connection:

[tun]
enabled = true
routes  = [
    "10.50.0.0/24",    # Dev network
    "192.168.1.0/24",  # Home network (stays direct)
]
mtu     = 1420

Database access

For direct database connections, use the SOCKS5 proxy:

# MySQL
mysql -h 10.50.0.20 -P 3306 --protocol=TCP

# PostgreSQL
psql -h 10.50.0.21 -p 5432

# MongoDB
mongosh "mongodb://10.50.0.22:27017"

Configure your database GUI (DBeaver, TablePlus, DataGrip) to connect via SOCKS5 at 127.0.0.1:1080.

Local development with webhooks

If your dev server calls back to localhost:3000 from a remote API, the VPN tunnel lets the remote API reach your local machine:

1. Your dev machine connects in TUN mode
2. The remote service calls your server’s public IP
3. The server tunnels the request through the VPN to your dev machine
4. Your local service responds through the tunnel

---

Multi-Cloud Setup

Connect servers across AWS, GCP, Azure, or other cloud providers into one private network without using cloud provider VPNs or exposing services to the public internet.

What this solves

• Cross-cloud databases without public endpoints
• Private communication between services in different cloud regions
• No need for cloud provider-specific VPN solutions
• Consistent network topology regardless of cloud provider

Architecture

AWS us-east-1 (10.0.0.0/24)     GCP europe-west1 (10.1.0.0/24)
        |                                |
  rvpn-server-TUN                  rvpn-server-TUN
  (10.0.0.1)                       (10.1.0.1)
        |                                |
        +-------- rvpn tunnel --------+
                    |
          Clients get IPs in
          respective DHCP ranges
          and can reach all subnets

Server configuration per cloud

AWS server.toml:

[server]
bind_address      = "0.0.0.0:443"
tls_cert_file     = "/etc/rvpn/certs/cert.pem"
tls_key_file      = "/etc/rvpn/certs/key.pem"
identity_key_file = "/etc/rvpn/server_identity.key"
websocket_path    = "/api/v1/ws"

[server.network]
nat_enabled = false           # NAT disabled - we want direct routing
dhcp_range  = "10.0.0.0/24"

[server.tun]
tun_ip      = "10.0.0.1/24"
dns_servers = ["10.0.0.53"]

GCP server.toml:

[server.network]
nat_enabled = false
dhcp_range  = "10.1.0.0/24"

[server.tun]
tun_ip      = "10.1.0.1/24"
dns_servers = ["10.1.0.53"]

Security groups and firewalls

Each cloud provider’s firewall must allow:

• Inbound TCP port 443 from the VPN tunnel IP ranges
• For cross-location communication, allow the other location’s VPN IP range

For AWS security groups:

Inbound: TCP 443 from 10.0.0.0/16 (VPN IP range)
Inbound: TCP 443 from 10.1.0.0/16 (Other cloud VPN range)

Client configuration

[tun]
enabled = true
routes  = ["10.0.0.0/8"]   # All private cloud ranges
mtu     = 1420

Use cases enabled

• Database replication between clouds: MySQL at 10.0.0.30:3306 to PostgreSQL at 10.1.0.30:5432
• Private container registries: registry.internal:5000 regardless of where it runs
• Internal APIs: api.internal:8080 without public endpoints
• Backup replication: rsync between servers without going over the public internet

---

Split Tunneling Guide

Split tunneling lets you decide which traffic goes through the VPN and which uses your normal internet connection.

When to use split tunneling

Use split tunneling for:

Scenario	Configure
Streaming services (Netflix, Spotify)	Bypass country or specific IPs
Gaming	Bypass game server IPs for lower latency
Local network devices	Bypass home/office LAN subnets
Banking apps	Bypass or tunnel depending on security policy
Development servers	Tunnel only your dev network

Avoid split tunneling for:

Scenario	Recommendation
Untrusted public Wi-Fi	Full tunnel
Accessing sensitive accounts	Full tunnel
Bypassing content filters at work	Full tunnel (may violate policy)

Understanding the bypass logic

Outgoing packet → Check bypass rules →
  → Matches bypass? → Send directly (no encryption)
  → No match? → Send through VPN tunnel

Bypass is checked before encryption. Matched traffic never enters the VPN tunnel.

Country bypass

[split_tunnel]
enabled                  = true
builtin_bypass_countries = ["CN", "HK", "SG", "JP", "KR", "TW"]

This bypasses traffic to IP addresses registered to those countries. Useful when:

• You are travelling abroad and want to access domestic content without slowdown
• Streaming services that block foreign IPs

Limitation: Country bypass uses APNIC IP range data. Large CDNs may serve content from IPs in multiple countries.

Network bypass (CIDR)

Bypass specific IP ranges regardless of country:

[split_tunnel]
enabled            = true
bypass_networks    = ["192.168.0.0/16", "10.0.0.0/8", "172.16.0.0/12"]

Typical bypass networks:

• 192.168.0.0/16 - Home/office LAN
• 10.0.0.0/8 - Private networks
• 172.16.0.0/12 - Docker, VPN, other private subnets

Domain-based bypass

Bypass traffic to specific domains:

[split_tunnel]
enabled            = true
bypass_domains_file = "~/.config/rvpn/bypass-domains.txt"

bypass-domains.txt:

netflix.com
spotify.com
hulu.com
disneyplus.com

Domain bypass uses DNS resolution: the domain is resolved locally (not through the VPN), and the resulting IPs bypass the tunnel.

Domain-based tunnel (force VPN)

Force specific domains through the VPN even if they would otherwise bypass:

[split_tunnel]
enabled            = true
tunnel_domains_file = "~/.config/rvpn/tunnel-domains.txt"

This is useful when:

• Your ISP throttles specific services
• You want to force streaming through the VPN for privacy

Ad blocking

[split_tunnel]
enabled   = true
block_ads = true

Blocks known ad and tracker domains at DNS level. Blocked domains return NXDOMAIN immediately. Works alongside bypass rules: bypassed domains are resolved locally without ad blocking.

Combining rules

Rules are evaluated in this order:

1. tunnel_networks / tunnel_domains (force through VPN)
2. bypass_networks / bypass_domains / builtin_bypass_countries (force direct)
3. Default (full tunnel if TUN mode, proxy if SOCKS5 mode)

Testing your split tunnel configuration

# Check your exit IP (should be VPN server if tunneled)
curl https://api.ipify.org

# Check a specific IP
curl --socks5 127.0.0.1:1080 https://api.ipify.org

# Test DNS resolution through tunnel
dig @127.0.0.1 example.com

# Trace routing
traceroute 8.8.8.8

Security considerations

When to use full tunnel (no split tunnel):

[split_tunnel]
enabled = false

• On untrusted public networks (coffee shop, hotel, airport Wi-Fi)
• When maximum privacy is required
• When bypass rules might accidentally exclude sensitive traffic

Risk of split tunneling:

Traffic that bypasses the VPN is visible to your ISP and local network operator. If you bypass banking sites, your ISP can see that you accessed them. Consider whether this is acceptable for your threat model.

Risk of country bypass:

Streaming services may detect VPN usage through other means (payment currency, account history, GPS location). Country bypass makes traffic appear domestic but does not change these other signals.