Network Requirements
Publisher → Broker
The publisher initiates all connections to the broker. No inbound ports need to be opened on the client's firewall.
| Direction | Protocol | Port | Purpose |
|---|---|---|---|
| Outbound | UDP | 51820–51830 | WireGuard tunnel to broker |
| Outbound | TCP | 443 | API communication (enrollment, heartbeat) |
Key point: The publisher only needs outbound access. No inbound firewall rules, no port forwarding, no public IP required. Works behind NAT, corporate firewalls, and CGNAT.
Client → Broker
| Direction | Protocol | Port | Purpose |
|---|---|---|---|
| Outbound | UDP | 51820 | WireGuard tunnel |
| Outbound | TCP | 443 | API (login, session renew, enrollment) |
Clients also only need outbound access. The tunnel uses UDP but will work through most corporate firewalls since it's outbound-initiated.
Firewall Considerations
- UDP must not be blocked: Some corporate firewalls block outbound UDP. If so, WireGuard cannot establish the tunnel. Verify with:
nc -uzv broker-host 51820 - Deep Packet Inspection (DPI): WireGuard uses a custom protocol that some DPI engines don't recognize. If your client is behind Netskope, Zscaler, or similar — add the broker IP to the bypass list.
- MTU: WireGuard adds ~60 bytes overhead. The default MTU of 1420 works in most environments. If you see HTTPS timeouts but pings work, reduce MTU to 1280.
Publisher Requirements
Operating System
| OS | Minimum Version | Notes |
|---|---|---|
| Ubuntu | 20.04 LTS | Kernel 5.6+ (WireGuard built-in) |
| Debian | 11 (Bullseye) | Kernel 5.10+ |
| Amazon Linux | 2023 | Requires modprobe wireguard |
| RHEL / Rocky / Alma | 8.4+ | Kernel 4.18 with backported WG module |
| Any Linux | Kernel ≥ 5.6 | WireGuard is built into the kernel since 5.6 |
Hardware
| Resource | Minimum | Recommended |
|---|---|---|
| CPU | 1 core (any architecture) | 1 core |
| RAM | 64 MB | 128 MB |
| Disk | 20 MB | 50 MB |
| Network | Any (works on 1 Mbps+) | Based on user throughput needs |
The publisher is an 8 MB static binary with no runtime dependencies. It runs on everything from a Raspberry Pi to a cloud VM.
Architecture Support
linux/amd64— Intel/AMD 64-bit (most servers and VMs)linux/arm64— ARM 64-bit (Raspberry Pi 4+, AWS Graviton, Azure Ampere)
Permissions
- Root access (or
CAP_NET_ADMIN+CAP_NET_RAW) for WireGuard interface creation iptablescommand must be available (for masquerade NAT)- IP forwarding enabled (
net.ipv4.ip_forward = 1— the installer sets this automatically)
Client Requirements
Supported Platforms
| Platform | Minimum Version | Tunnel Method | Split DNS |
|---|---|---|---|
| macOS | 12 (Monterey) | wireguard-go (userspace) | /etc/resolver/ files |
| Windows | 10 (1809+) | wintun (embedded in MSI) | NRPT rules |
| Linux | Kernel 5.6+ (or wireguard-go) | Kernel WireGuard module | systemd-resolved |
| Android | 10+ | VpnService + wireguard-android | VpnService.Builder |
| iOS | 15+ | NetworkExtension + WireGuardKit | NEDNSSettings |
Client Dependencies
| Platform | What's Needed |
|---|---|
| macOS | brew install wireguard-go wireguard-tools |
| Windows | Nothing — MSI installer includes everything (wintun embedded) |
| Linux (kernel 5.6+) | Nothing — kernel WireGuard module is built-in |
| Linux (older kernels) | wireguard-go (userspace fallback) |
Privilege Requirements
| Platform | Default | Rootless Option |
|---|---|---|
| macOS | sudo | Privileged helper (future) |
| Windows | Administrator (UAC prompt) | Add user to Network Configuration Operators group |
| Linux | sudo | setcap 'cap_net_admin+ep cap_net_raw+ep' on the binary |
DNS Requirements
For split DNS to work (resolving internal zones through the tunnel), the publisher needs:
- A DNS server on the private network that resolves the internal zones (e.g.,
10.50.1.2:53for*.internal.company.com) - That DNS server IP must be within the publisher's exposed CIDRs (or explicitly added to WireGuard AllowedIPs — the reconciler handles this automatically)
The client does not need any DNS configuration — the WireZTNA client sets up split DNS automatically on connect.
Bandwidth and Latency
- Throughput: WireGuard crypto runs at line speed on modern CPUs (~1 Gbps on a single core with AES-NI/NEON)
- Overhead: ~60 bytes per packet (WireGuard header + UDP + IP). Negligible for most workloads.
- Latency: Adds one round-trip to the broker per packet (client → broker → publisher). Keep the broker geographically close to your users/publishers for optimal latency.
- Keepalive: WireGuard sends a 32-byte keepalive every 25 seconds to maintain NAT mappings. Bandwidth impact: ~1 KB/min per tunnel.
Quick Checklist
☐
Publisher can reach broker on UDP 51820 (outbound)
☐
Publisher can reach broker on TCP 443 (outbound, HTTPS)
☐
Publisher host has Linux kernel 5.6+ (or WireGuard module loaded)
☐
Publisher host has root access and iptables available
☐
Client can reach broker on UDP 51820 (outbound)
☐
Client can reach broker on TCP 443 (outbound)
☐
No DPI/proxy blocking outbound UDP on client network