ROCHESTONZelfire.

SECURE TUNNELING

ZelTunnel

Connect through a secure tunnel.

ZelTunnel provides secure TCP and UDP tunneling through HTTPS. Explore its dedicated website for the platform, supported workflows, and connection information.

Visit ZelTunnel website Explore the suite

ZelTunnel

Secure tunneling

ROCHESTON ZELFIRE ECOSYSTEM

BUILT FOR YOUR WORKFLOW

What you can do.

TCP tunneling

Connect TCP traffic through an HTTPS tunnel.

UDP tunneling

Support UDP tunneling workflows.

Dedicated documentation

Find connection details on the ZelTunnel website.

THE COMPLETE PRODUCT GUIDE

Explore ZelTunnel.

Get to know the capabilities, workflows, and intelligence behind the product.

01

HTTPS Tunneling Powered by Agentic AI.

WSS now • QUIC-ready • Agent-powered

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.

TCPRDP, SSH, databases, custom apps
UDPDNS, RDP UDP, games, packet services
443HTTPS-friendly access path
ACLToken-scoped target policy
 AIAutonomous policy & provisioning
Dashboard
02

A focused tunnel for services, not a broad network VPN.

What it is

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.

Precise scope: ZelTunnel tunnels service ports. It is not raw IP routing, ICMP tunneling, Ethernet bridging, or full private network access.
↔

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.

03

The app sees localhost. The firewall sees HTTPS.

How it works

The client authenticates to the tunnel server, the server checks target permissions, then raw TCP streams and UDP packets move through the encrypted tunnel.

Application
RDP / SSH / DB / UDP app

Connects to localhost instead of a private address.

›
Client
127.0.0.1:3390

ZelTunnel accepts TCP and UDP traffic locally.

›
Tunnel
WSS/TCP 443 · QUIC/UDP 443

Traffic is encrypted through one endpoint.

›
Target
2.3.3.3:3389

The server forwards only after policy allows it.

Application-protocol blind Token authenticated Target ACLs No open proxy by default Payload logging avoided QUIC-ready design
04

Secure access when the port is blocked, private, or risky to expose.

Problems solved

Use one public HTTPS endpoint for exact service access instead of opening many firewall rules or placing users on an entire network.

443

Restrictive firewalls

Forward RDP, SSH, databases, DNS, games, and custom ports through normal HTTPS.

NAT

NAT traversal

Reach machines behind home routers, CGNAT, and corporate NAT without inbound port forwarding.

VPN

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.

05

Narrow port access instead of broad network access.

VPN Comparison

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.

CapabilityZelTunnelTraditional VPN
Access modelSpecific ports and approved targetsRoutes, subnets, and broad network reach
Firewall visibilityHTTPS endpoint, QUIC optional on UDP/443VPN protocols and ports may need approval
Blast radiusPer-token target ACLsDepends on network segmentation
User workflowRun client, connect app to localhostProfiles, routes, DNS, split tunnel rules
Best fitRDP, SSH, DBs, DNS, admin toolsFull remote network access
06

Start the tunnel, then point apps at localhost.

Run

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
RDP user actionOpen Microsoft Remote Desktop to 127.0.0.1:3390.
Firewall viewThe network sees HTTPS traffic to tunnel.rocheston.com.
Admin viewServer policy controls targets, reverse listeners, limits, and revocation.
07

Keep WSS. Add QUIC where UDP/443 is open.

QUIC

QUIC should become the high-performance transport for networks that allow UDP/443. WSS remains the mandatory fallback for locked-down HTTPS-only networks.

WSS baseline QUIC next Auto fallback
Production rule: open inbound 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
08

ZelTunnel plugs into Novazel as the secure access layer.

Novazel Integration

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.

N

Novazel orchestration

Novazel handles the agentic intent, workflow, and decision loop while ZelTunnel provides the controlled network path to the approved service.

Z

ZelTunnel transport

ZelTunnel carries RDP, SSH, database, DNS, and custom TCP/UDP traffic through a policy-enforced HTTPS tunnel.

ACL

Scoped access

Access remains token-bound, target-specific, revocable, and auditable instead of exposing broad network routes.

AI

Agent-ready telemetry

Health, metrics, auth events, byte counts, and audit traces give Novazel the signals it needs to reason and act.

09

The tunnel that thinks, acts, and self-governs.

Agentic AI

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.

Input/metrics & /healthAuth failures, byte counts, connection timing
→
AgentReason & DecideBehavioral baseline, policy graph, risk score
→
ActionRevoke / Provision / ReconnectWrites YAML, calls token API, triggers alert
→
OutputAudit TraceEvery decision logged with rationale and timestamp
10

Built for policy-driven, auditable service access.

Technical features

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
11

The client requests. The server decides.

Security model

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
12

One HTTPS endpoint. Any authorized TCP or UDP port.

Zelsuite tunnel layer

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.

THE DETAILS THAT MATTER

ZelTunnel FAQ.

Answers about the product, its capabilities, and how it fits into your security workflow.

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.

Part of a connected security ecosystem.

Explore how AINA connects intelligence across Zelfire, and find the products that complement your workflow.

Meet AINA

Explore more of Zelfire.

All products
Build & connect

ZelCode

Code security & DevSecOps

Find vulnerabilities, insecure patterns, and exposed secrets in source code.

Overview Visit website
Build & connect

ZelC

Cybersecurity programming

Express security intent in Rocheston’s cybersecurity programming language.

Overview Visit website

LET’S CONNECT YOUR DEFENSE

Put Zelfire to work.

Explore the products, see the workflows, and talk to Rocheston about your security environment.

Request a demo

Product screenshot