HTTPS Tunneling Powered by Agentic AI.
ZelTunnel gives users precise TCP and UDP service access through one encrypted endpoint. Apps connect to localhost, the firewall sees HTTPS, and a built-in Agentic AI layer provisions access, detects anomalies, and self-heals — autonomously, without a human in the loop.
A focused tunnel for services, not a broad network VPN.
ZelTunnel wraps TCP streams and UDP packets into encrypted tunnel frames. It does not need to parse RDP, SSH, MySQL, DNS, or your custom protocol.
Local forwarding
Users connect to a local port while ZelTunnel carries traffic to an approved remote target.
Reverse forwarding
Machines behind NAT connect outward and expose controlled remote listeners through policy.
Protocol any
One command can create TCP and UDP listeners for mixed protocols such as RDP.
Transport auto
WSS stays the reliable HTTPS path, while QUIC can become the fast UDP/443 path.
The app sees localhost. The firewall sees HTTPS.
The client authenticates to the tunnel server, the server checks target permissions, then raw TCP streams and UDP packets move through the encrypted tunnel.
Connects to localhost instead of a private address.
ZelTunnel accepts TCP and UDP traffic locally.
Traffic is encrypted through one endpoint.
The server forwards only after policy allows it.
Secure access when the port is blocked, private, or risky to expose.
Use one public HTTPS endpoint for exact service access instead of opening many firewall rules or placing users on an entire network.
Restrictive firewalls
Forward RDP, SSH, databases, DNS, games, and custom ports through normal HTTPS.
NAT traversal
Reach machines behind home routers, CGNAT, and corporate NAT without inbound port forwarding.
No full VPN setup
Grant one service instead of routing a user onto a whole private network.
Temporary access
Create scoped access for support, labs, training, contractors, and incident response.
Legacy apps
Bring old tools and custom services behind an authenticated modern tunnel layer.
Central control
One endpoint, one TLS layer, one policy engine, and one place to revoke access.
Narrow port access instead of broad network access.
VPNs are excellent for full network routing. ZelTunnel is better when a user only needs a specific TCP or UDP service, especially through HTTPS-only networks.
| Capability | ZelTunnel | Traditional VPN |
|---|---|---|
| Access model | Specific ports and approved targets | Routes, subnets, and broad network reach |
| Firewall visibility | HTTPS endpoint, QUIC optional on UDP/443 | VPN protocols and ports may need approval |
| Blast radius | Per-token target ACLs | Depends on network segmentation |
| User workflow | Run client, connect app to localhost | Profiles, routes, DNS, split tunnel rules |
| Best fit | RDP, SSH, DBs, DNS, admin tools | Full remote network access |
Start the tunnel, then point apps at localhost.
The user-facing workflow stays simple: authenticate, bind a local port, and connect the normal client application to that port.
# 1. Generate dev certificate zeltunnel cert generate \ --out certs \ --server-name tunnel.rocheston.com # 2. Hash token zeltunnel token hash MY_SECRET_TOKEN # 3. Start server zeltunnel server \ --config examples/server.yml
# RDP-style local forward zeltunnel connect \ --server https://tunnel.rocheston.com \ --token MY_SECRET_TOKEN \ --listen 127.0.0.1:3390 \ --target 2.3.3.3:3389 \ --protocol any \ --transport auto # Reverse tunnel zeltunnel reverse \ --server https://tunnel.rocheston.com \ --token MY_SECRET_TOKEN \ --remote-listen 0.0.0.0:3390 \ --target 127.0.0.1:3389 \ --protocol any
127.0.0.1:3390.tunnel.rocheston.com.Keep WSS. Add QUIC where UDP/443 is open.
QUIC should become the high-performance transport for networks that allow UDP/443. WSS remains the mandatory fallback for locked-down HTTPS-only networks.
TCP 443 for WSS/HTTPS and UDP 443 for QUIC. If UDP/443 is blocked, clients still use WSS fallback.# Force QUIC only zeltunnel connect \ --server https://tunnel.rocheston.com \ --token MY_SECRET_TOKEN \ --listen 127.0.0.1:3390 \ --target 2.3.3.3:3389 \ --protocol any \ --transport quic # Smart mode: QUIC first, WSS fallback zeltunnel connect \ --server https://tunnel.rocheston.com \ --token MY_SECRET_TOKEN \ --listen 127.0.0.1:3390 \ --target 2.3.3.3:3389 \ --protocol any \ --transport auto
ZelTunnel plugs into Novazel as the secure access layer.
Novazel can use ZelTunnel to open precise, auditable paths to protected TCP and UDP services. The tunnel stays narrow, policy-scoped, and observable while Novazel coordinates the higher-level agentic workflow.
Novazel orchestration
Novazel handles the agentic intent, workflow, and decision loop while ZelTunnel provides the controlled network path to the approved service.
ZelTunnel transport
ZelTunnel carries RDP, SSH, database, DNS, and custom TCP/UDP traffic through a policy-enforced HTTPS tunnel.
Scoped access
Access remains token-bound, target-specific, revocable, and auditable instead of exposing broad network routes.
Agent-ready telemetry
Health, metrics, auth events, byte counts, and audit traces give Novazel the signals it needs to reason and act.
See ZelTunnel in action.
Real screenshots from across the ZelTunnel ecosystem — dashboards, policy editors, agent consoles, and live tunnel flows.
The tunnel that thinks, acts, and self-governs.
Five autonomous agents operate on ZelTunnel's existing metrics, policy YAML, token system, and health endpoints — no payload access, pure behavioral intelligence.
Policy Agent
Monitors auth failures and byte anomalies from /metrics. When a token exceeds its behavioral baseline, the agent rewrites ACLs, revokes the token, and queues an admin alert — no human required.
Provisioning Agent
Natural-language or API request → agent generates a time-scoped token, adds the ACL entry to server config, delivers the connect command to the user, and schedules auto-expiry cleanup.
Threat-Response Agent
Correlates audit metadata — targets, timing, auth results, byte counts — to detect suspicious sessions. Triggers revocation and writes an incident trace. Never touches payload contents.
Self-Healing Agent
Detects tunnel drops via the health endpoint, classifies the cause (idle timeout vs. auth revocation vs. network fault), and reconnects automatically when policy still permits.
Zero-Trust Access Agent
Evaluates access requests against role, device, time, and target risk. Approves or denies with a logged rationale. Provisions short-lived tokens on approval and auto-deprovisions at expiry.
Observe → Reason → Act
Every agent follows the same loop: read from ZelTunnel's existing observability layer, reason against policy, take a targeted action, and write an audit trace. No guesswork, no broad access.
Built for policy-driven, auditable service access.
Simple for users, strict for administrators: authenticated, scoped, observable, and safe by default.
Transport
- ✓WSS/HTTPS tunnel over TCP/443
- ✓Transport auto with fallback behavior
- ✓QUIC design for streams and datagrams
Forwarding
- ✓Local TCP and UDP forwarding
- ✓Reverse TCP and UDP forwarding
- ✓Protocol any creates TCP + UDP listeners
Security
- ✓Token authentication with hashed tokens
- ✓Server-side target ACLs
- ✓No open proxy by default
Admin controls
- ✓Per-user targets and reverse listen rules
- ✓Connection limits and idle timeouts
- ✓Public binds require explicit approval
Observability
- ✓Health and metrics endpoints
- ✓Bytes, connection counts, auth failures
- ✓Audit metadata for tunnel use
Developer experience
- ✓One-shot connect command
- ✓YAML config for repeatable tunnels
- ✓Token and certificate helpers
The client requests. The server decides.
ZelTunnel should enforce authorization server-side. A client can ask for a target, but policy determines whether the target is allowed for that token.
auth: tokens: - id: "dev-user" token_sha256: "...hashed-token..." allowed_targets: - "2.3.3.3:3389" - "10.0.0.0/8:22" - "192.168.0.0/16:3389" security: allow_open_proxy: false allow_public_bind_default: false
Common questions
Is this HTTP tunneling? +
Yes. The current baseline is WSS/HTTPS tunneling for TCP and UDP port traffic, wrapping application traffic inside encrypted tunnel frames.
Does it inspect RDP, SSH, or MySQL? +
No. ZelTunnel is application-protocol blind and forwards TCP bytes or UDP packets without parsing the application protocol.
Can it tunnel UDP through HTTPS? +
Yes. UDP packet boundaries are preserved inside tunnel frames. QUIC is the preferred future transport for better UDP behavior where UDP/443 is available.
Is ZelTunnel a VPN replacement? +
It can replace VPNs for specific service access such as RDP, SSH, databases, and DNS. It is not full network routing.
What does the user install? +
The user runs the ZelTunnel client and connects their normal app to a local port, such as 127.0.0.1:3390 for Remote Desktop.
How is access controlled? +
Access is controlled by server-side token policy: allowed targets, ports, reverse listeners, limits, and timeouts.
Does it expose an open proxy? +
No. Open proxy behavior is disabled by default, and broad target access must be explicitly configured.
What does the firewall see? +
The firewall sees encrypted traffic to the ZelTunnel server, usually HTTPS on TCP/443.
Can it run reverse tunnels? +
Yes. Reverse tunnels let a protected machine connect outward and expose an approved remote listener.
Does it log user traffic? +
It should log operational metadata such as auth results, targets, byte counts, and timing, not payload contents.
Where should the server run? +
Anywhere users can reach over HTTPS and where the server can reach approved targets: cloud VM, DMZ host, or internal endpoint behind a load balancer.
Can it be used for databases and admin tools? +
Yes. Any permitted TCP service can be forwarded, including PostgreSQL, MySQL, MSSQL, Redis, SSH, RDP, and web admin panels.
One HTTPS endpoint. Any authorized TCP or UDP port.
Give users precise, auditable access to every authorized service. An agentic policy layer governs provisioning, revocation, and self-healing — keeping access narrow and the network quiet.