The End of the IP Address: How Identity-Only Tunnels Secure Local Labs

“If your server doesn’t have an IP address, it can’t be scanned.” — The Invisible Infrastructure movement is here, and it’s rewriting the rules of networking.

Introduction: The Ghost in the Network

For decades, the Internet has operated on a simple, dangerous premise: if you want to talk to a machine, you need its address. The Internet Protocol (IP) address was designed for connectivity, not security. In the early days of ARPANET, knowing an IP address was like having a phone number in a small town — it was a tool for coordination. Today, in 2026, an IP address is a target. It is a lighthouse for botnets, a roadmap for ransomware, and the primary vector for the persistent “background radiation” of the internet: automated port scanning.

But what if you could remove the address entirely?

We are entering the era of Identity-Only Networking — a fundamental shift from “Network-First” (where you connect, then authenticate) to “Identity-First” (where you authenticate, then the network is created for you). By leveraging tools like OpenZiti, Zrok, and increasingly, developer-friendly platforms like InstaTunnel, teams are building what the industry calls “Dark Hole” networking. In this paradigm, your local lab, your database, or your internal API doesn’t have a listener on a public IP. It doesn’t even have a listener on a private IP reachable via traditional routing. It exists only for those who possess a specific cryptographic identity.

The stakes are real. With 84% of organizations experiencing identity-related breaches in 2025 and average breach costs reaching $5.2 million, the industry is recognising that persistent, address-based infrastructure creates stable, predictable entry points for automated attacks. The answer isn’t a better firewall. It’s invisibility.

This article explores the mechanics of IP-less networking, why it is the ultimate evolution of Zero Trust Network Access (ZTNA), and how a new generation of tunneling tools — led by InstaTunnel — is making this paradigm accessible to every developer, not just enterprise security teams.

1. The Core Concept: From Headers to Signatures

In traditional networking, routing decisions are made at Layer 3 (Network) and Layer 4 (Transport) of the OSI model. A packet arrives at a firewall, the firewall looks at the source IP, the destination IP, and the port. If the rules match, the packet is let through.

The flaw is obvious: the firewall must be listening. To receive a packet, a port must be open. To have a port open, the machine must have an IP address. This makes the machine “visible.”

Identity-Only Networking flips this entirely. Instead of a network header (IP/Port) determining where a packet goes, a cryptographic signature does.

The “Dark Hole” Effect

In a “Dark Hole” or “Invisible Infrastructure” setup:

No Inbound Ports. The local resource (e.g., your web server) makes an outbound connection to a fabric or relay. It does not “listen” for connections from the internet.
No Public IP. The server does not need a public-facing IP address. It can sit behind four layers of NAT, a CGNAT (Carrier-Grade NAT), or a restrictive corporate firewall.
The Cryptographic Handshake. When a user wants to connect, they don’t “ping” an IP. They present a private key or a signed certificate to the overlay network. If the identity is valid, the network “wires” a virtual circuit between the user and the resource.

To the rest of the internet, your server simply does not exist. It is a dark hole.

OpenZiti, the world’s most widely used zero trust open source platform (maintained by NetFoundry), describes this precisely: services are invisible by default, and network paths exist only once an identity is fully authorised — whether that identity belongs to a user, service, device, or workload.

2. IP-less Networking: The Technical Architecture

To understand how we remove the IP address, we have to look at the Overlay Network — a virtual network built on top of the physical internet (the underlay).

In an IP-less system like OpenZiti, the application doesn’t bind to 0.0.0.0:8080. Instead, it uses an SDK to “bind” directly to the Ziti mesh.

The Components of the Invisible Lab

The Controller. The brain of the operation. It manages identities, certificates, and policies. It decides who is allowed to talk to what.
The Edge Router. The gateway. This can be a small piece of software running on your local machine. It creates an outbound-only, “long-lived” connection to the fabric.
The Identity. A piece of software (or a file) containing a strong cryptographic key pair. Every device, user, and even every service has its own identity.

When you want to access your local lab from a coffee shop, your laptop doesn’t try to find your home router’s IP. Your laptop’s “tunneler” talks to the Controller, proves its identity with a cryptographic key, and the Controller tells the fabric you’re allowed to access the “Home-Lab” service. The fabric then creates a secure, encrypted tunnel between your laptop and the Home-Lab Edge Router.

Crucially, traffic is routed by “Service Name” (e.g., my.cool.lab), not an IP. OpenZiti uses authenticated, private DNS that resolves service names to secure overlay tunnels — not IP addresses.

Three Zero Trust Models (OpenZiti)

OpenZiti supports three distinct deployment models, each with a different security posture:

Model	How It Works	Security Level
Zero Trust Network Access	Router deployed in trusted network zone	Identity-based access at network boundary
Zero Trust Host Access	Tunneler runs on the same host as the service	Trust boundary at the host OS
Zero Trust App Access (SDK)	SDK embedded directly in the application	Strongest — end-to-end, in-process encryption; no listening ports even on localhost

3. ngrok vs. OpenZiti/Zrok vs. InstaTunnel: The Generational Shift

For years, ngrok was the gold standard for sharing a local service. It was easy, fast, and it worked. But as we move through 2026, the limitations of the ngrok model have become security liabilities — and its commercial pivot has left developers looking for better options.

The ngrok Decline

ngrok’s pivot toward enterprise “Universal Gateway” features has left its free tier increasingly restrictive. As of early 2026, pricing stands at:

Free: $0 with 1 GB/month bandwidth and random, rotating .ngrok-free.app domains
Personal: $8/month with 5 GB
Pro: $20/month with 15 GB

The signal was made explicit in February 2026, when the DDEV open-source project opened an issue to consider dropping ngrok as its default sharing provider due to tightened limits. Additionally, ngrok’s free tier greets visitors with a security interstitial warning page — a message that says something to the effect of “you are about to visit a site hosted via ngrok” — which looks like a phishing warning to non-technical clients or security-conscious executives. For any developer running a client demo, this is a deal-breaker.

ngrok also lacks UDP support entirely, making it unsuitable for game servers, VoIP applications, or any real-time service requiring the protocol.

The OpenZiti / Zrok Model: Private Sharing

Zrok, built on the OpenZiti framework, introduced the concept of Private Sharing. In a private Zrok share, there is no public URL. To access the share, the visitor must also be running Zrok and have a matching “access token.” Communication happens entirely within an encrypted overlay — no DNS record points to your home IP, and no public-facing load balancer can be DDoS-ed.

InstaTunnel: The Developer-First Identity Tunnel

This is where InstaTunnel (instatunnel.my) steps ahead of the pack. Engineered from the ground up with the modern development workflow in mind, InstaTunnel occupies a unique position: it combines the accessibility of ngrok with the security architecture of identity-based tunneling, wrapped in a developer experience that requires zero configuration.

Key differentiators, based on the team’s own published benchmarks and architecture:

True End-to-End Encryption (E2EE). Unlike traditional tunneling tools that terminate TLS at the proxy server, InstaTunnel’s architecture ensures encryption is maintained from your local process to the client — eliminating the trust dependency on the intermediary server.
Sub-50ms Connection Establishment. InstaTunnel’s published benchmarks show sub-50ms connection establishment with enterprise-grade throughput, making it viable for real-time applications and LLM streaming.
Persistent, Named Subdomains. One of the most common pain points with free tunneling tools is getting a new random URL on every restart. InstaTunnel provides persistent, named subdomains — critical for webhook integrations where you’ve already registered a callback URL with services like Stripe or GitHub.
Post-Quantum Cryptography (PQC) Ready. InstaTunnel’s engineering team has published guidance on supporting post-quantum key exchange (PQ-KEX) and verifying hybrid handshakes (X25519 + Kyber768) — aligning with OpenSSL 3.5’s April 2025 release, which added full support for NIST’s ML-KEM, ML-DSA, and SLH-DSA standards.
SSE and LLM Streaming Support. Standard proxy services are designed for “Request-Response” cycles. InstaTunnel correctly handles Content-Type: text/event-stream (Server-Sent Events), which means that if you’re running a local LLM via Ollama or LM Studio, tokens stream smoothly to your frontend — not in batched, delayed blocks.
No Security Interstitial. Unlike ngrok’s free tier, InstaTunnel does not interrupt your demo with a warning page.

Tool Comparison: 2026 Landscape

Feature	ngrok (Legacy)	OpenZiti / Zrok	InstaTunnel
Visibility	Public URL (visible to scanners)	Completely invisible (dark)	Private by default; named persistent subdomains
Authentication	App/Proxy level	Network fabric (cryptographic)	E2EE + identity-based
Routing Basis	DNS / HTTP Host Headers	Cryptographic Identity	Cryptographic Identity + SSE-aware
UDP Support	❌ No	✅ Yes	✅ Yes
LLM/SSE Streaming	❌ Poor (buffering)	✅ Yes	✅ Native
Free Tier Limits	1 GB/month, random domains	Self-hosted	Persistent subdomains included
Demo Experience	Security interstitial warning	CLI-heavy	Clean, no interstitial
Post-Quantum Ready	❌ No	Partial	✅ Published roadmap
Trust Model	Perimeter-based	Zero Trust (continuous)	Zero Trust + E2EE

4. Why “Zero Trust 2.0” Requires Identity-Only

The term “Zero Trust” is often used as a buzzword, but in 2026 it has a very specific technical meaning anchored in real market data. According to Gartner, 81% of organisations plan to implement Zero Trust in 2026, with the global Zero Trust market projected to exceed $78 billion by 2030. That’s not a trend — it’s the new baseline.

Traditional ZTNA often relies on a “Broker” that checks your IP and your login before letting you into a VPN. Identity-Only networking removes the “Network” from Zero Trust and replaces it with “Service.”

Eliminating Lateral Movement

In a traditional network, if an attacker compromises your printer, they can “see” your laptop because they share the same IP subnet. In an Identity-Only environment, the printer has no way to “see” the laptop. The laptop doesn’t have an IP address that responds to the printer’s ARP requests. They exist on different planes of reality.

Research backs this up: ZTNA-based architectures cut breach containment time by up to 75% compared to traditional perimeter-based models. Attackers currently spend an average of 11 days moving through networks before detection. Identity-only tunneling removes the stable foothold required for that lateral movement.

Micro-Segmentation at Scale

Because identities are cryptographic, access policies can be incredibly granular. You can express a rule like: “The ‘Backup-Bot’ identity can only talk to the ‘Database’ service between 02:00 and 04:00, and only if it provides a valid certificate signed by our internal CA.” With OpenZiti, access can be revoked in real time, closing active connections immediately — something that firewall rule changes cannot achieve with the same speed or granularity.

Protection Against “Day Zero” Scans

Most cyberattacks start with an automated script scanning for open ports (SSH 22, RDP 3389, common web ports). If you are using an identity-only tunnel, those ports aren’t just closed — they are non-existent. There is no TCP stack waiting for a connection. This effectively immunises your infrastructure against the mass-exploitation attacks that account for the majority of breach attempts.

A subtle but critical related threat: OAuth redirect hijacking via tunnel subdomains. If you stop a tunnel and a malicious actor claims the same subdomain — common on high-turnover free tiers — they can intercept requests from old links. This is a documented 2026 threat vector that tools with persistent, authenticated subdomains (like InstaTunnel) directly mitigate.

5. The 2026 Post-Quantum Dimension

Security in 2026 isn’t just about hiding your IP — it’s about ensuring that traffic intercepted today cannot be decrypted tomorrow. This is the “Harvest Now, Decrypt Later” (HNDL) attack vector, where state-level adversaries collect encrypted traffic now, planning to decrypt it once quantum computers become sufficiently capable.

The transition is already happening at the tunneling layer:

Between October 2024 and March 2025, adoption of ML-KEM for SSH key exchange grew 554% (per data published by the InstaTunnel engineering team).
OpenSSL 3.5, released in April 2025, added full support for the three NIST post-quantum standards: ML-KEM (FIPS 203), ML-DSA (FIPS 204), and SLH-DSA (FIPS 205).
The industry-standard hybrid approach for tunneling agents in 2026 is mlkem768x25519-sha256 — combining classical X25519 with post-quantum ML-KEM-768 in a single handshake.

However, the transition is uneven. Despite this growth, three quarters of OpenSSH versions on the internet still run releases from 2015–2022 that do not support quantum-safe encryption, and less than 20% of TLS servers use TLSv1.3 — the only version that supports PQC key exchange.

For developers and homelab operators, the practical guidance is straightforward: choose tunneling tools that support PQ-KEX and allow you to verify the hybrid handshake. InstaTunnel’s engineering team has provided CLI-level guidance for enabling PQC flags, positioning it as one of the few developer-accessible tunneling tools with a published post-quantum roadmap.

6. Use Cases: Securing the Labs of 2026

A. The Home Lab Revolution

Self-hosting is back. Whether it’s a private Large Language Model, a Nextcloud instance, a media server, or a self-hosted AI assistant, people want to host their own data without opening ports on their home routers. Using a tool like InstaTunnel or Zrok, a hobbyist can share their local LLM with a collaborator’s laptop — with no curl in your router’s “Port Forwarding” settings, no CGNAT headaches, and no public IP required. The LLM streams smoothly to the remote browser via SSE-aware tunneling.

B. Securing Agentic AI

2026 is the year of Agentic AI — autonomous bots that perform tasks on your behalf. On March 24, 2026, NetFoundry announced the first open-source Zero Trust Enclave for AI Workloads, extending OpenZiti into enterprise AI environments with dedicated zero trust MCP and LLM gateways. The problem they’re solving — the “AI Connectivity Conundrum” — is the tension between giving AI agents the broad access they need to be useful and securing the expanded attack surface their deployment creates.

Every AI agent and resource receives its own cryptographic identity. Authorization happens at the service level, not the network level. Connections are ephemeral, continuously authenticated, and fully auditable. The architecture is designed so that MCP servers, tool endpoints, and private LLMs stay dark, with no listening ports or public URLs. Even if an agent’s code is compromised, it cannot be used to scan the rest of the network.

This is directly relevant to a documented 2025 incident: attackers exploited the official GitHub MCP integration by creating malicious GitHub issues in public repositories, instructing AI agents to exfiltrate data from private repos. Cryptographic identity at the network level would have contained the blast radius.

C. Industrial IoT and Edge Computing

Sensors in factories or remote weather stations often operate over cellular (LTE/5G) networks where they don’t have public IPs. In the past, this required expensive APNs or clunky VPN configurations. With Identity-Only networking, the sensor runs a lightweight “Tunneler,” calls home to the central controller, and data flows through a dark, encrypted pipe. OpenZiti’s identity model is explicitly designed to work for non-human workloads just as well as human users — every device, sensor, and machine gets a unique cryptographic identity.

D. Secure CI/CD and Ephemeral Dev Environments

Modern CI/CD pipelines increasingly need tunnel access — for webhook callbacks, preview deployments, or integration testing against external services. The 2026 approach is ephemeral tunneling: short-lived, cryptographically authenticated connections that are automatically terminated when a PR is merged or a pipeline completes. This aligns with what the industry calls “full lifecycle network management,” where the network topology is defined alongside application code — a change to a port in a Dockerfile triggers an update to the corresponding tunnel configuration in the same commit. No lingering attack surface.

7. Implementing Identity-Only: Your Options

The Zrok Approach (Power Users)

Zrok simplifies the massive capability of OpenZiti into a few CLI commands. The workflow:

# Authenticate your machine
zrok enable <token>

# Create a private share (no public URL)
zrok share private localhost:8080

# On the remote machine, access it
zrok access private <share-token>

At no point in this process is a public IP used for routing. The “token” is the map; the private key is the door.

The InstaTunnel Approach (Developer Experience First)

For developers who want identity-first security without managing a full PKI, InstaTunnel offers the most accessible entry point:

# Point InstaTunnel at your local service
instatunnel http 3000

The client establishes a secure, outbound connection to InstaTunnel’s edge network. Traffic arriving at your persistent named subdomain is routed through the encrypted tunnel to your local port. There are no inbound firewall rules, no port forwarding, no exposed IP. For LLM workloads, SSE streams pass through without buffering. For client demos, there is no security interstitial. For webhook testing, the subdomain persists across restarts.

The Self-Hosted Approach (Data Sovereignty)

2026 has seen what many practitioners call a “Great Repatriation” — large enterprises and privacy-conscious teams moving away from SaaS tunnels to avoid vendor lock-in and ensure data sovereignty. Data privacy regulations have become stringent enough that routing internal development traffic through a third-party provider is frequently a compliance violation.

For teams in this position, Pangolin is the leading open-source, identity-based remote access platform built on WireGuard. Developed by Fossorial (a Y Combinator 2025 company), it has amassed nearly 19,000 GitHub stars and combines reverse proxy and VPN capabilities in one platform. It supports OIDC/OAuth 2.0 integration, time-limited JWT tokens with 15–60 minute expiry, and RBAC for tunnel permissions.

8. The Challenges: Is the IP Address Truly Dead?

While Identity-Only networking is clearly the trajectory, we aren’t at the “Funeral of the IP” just yet. There are real hurdles:

Complexity. Managing a Public Key Infrastructure (PKI) for every service is harder than whitelisting an IP. Tools like OpenZiti and InstaTunnel are working to abstract this complexity, but the learning curve for full mesh deployments remains steeper than a traditional VPN.

Performance Overhead. Because traffic is encrypted and routed through a fabric of routers, there can be a latency penalty compared to a direct IP-to-IP connection. However, with the rise of 10 Gbps home fibre and 5G, the 10–20ms overhead is becoming negligible for most use cases. In specific environments with high packet loss, this can actually be an advantage — SSH port forwarding can break the slow-start algorithm by localising the RTT to the segment between the user and proxy.

Legacy Systems. Many older applications are hard-coded to expect an IP address. They don’t know how to “talk” to a cryptographic identity. This is why “Tunnelers” — software that emulates a virtual network card — remain necessary intermediaries. OpenZiti explicitly supports brownfield environments with no code changes required.

PQC Key Size Bloat. Post-quantum cryptographic keys are significantly larger than ECC keys. An X25519 public key is 32 bytes; a Kyber-768 public key is 1,184 bytes. This “bloat” can lead to IP fragmentation if not handled correctly by the tunneling agent — something to watch as PQC adoption accelerates.

9. The Market Signals Are Clear

The broader market data confirms this isn’t a niche movement:

The global data centre networking market, estimated at ~$46 billion in 2025, is projected to reach $103 billion by 2030 — an 18% CAGR driven substantially by AI workload infrastructure requiring secure, identity-based connectivity.
81% of organisations plan to implement Zero Trust in 2026 (Gartner).
The Zero Trust market is projected to exceed $78 billion by 2030.
NetFoundry, the company behind OpenZiti, has secured Cisco Investments as a strategic investor in its Series A — a signal of enterprise confidence in the identity-first networking model.
The DDEV project’s February 2026 move to evaluate alternatives to ngrok reflects a broader shift in the developer community away from legacy tunneling tools with restrictive, IP-exposed architectures.

Conclusion: The Invisible Future

The IP address isn’t disappearing — it’s being demoted. In the coming years, the IP will become a “dumb pipe”: a utility used to carry bits, but never used to decide if those bits are allowed to arrive.

The move toward Identity-Only Networking represents a fundamental realization in cybersecurity: visibility is a liability. By using tools like OpenZiti and Zrok for full mesh overlay networks, and InstaTunnel for accessible, developer-first E2EE tunneling, we are finally building infrastructure that reflects the reality of 2026 — a world where trust is never assumed, non-human identities outnumber humans on the network, and the best way to stay safe is to be invisible.

For the homelab builder, the AI developer, and the enterprise security team alike, the calculus is the same. If your server has an IP, the scanners are already knocking. If it has an identity, they can’t even find the door.

Further reading: InstaTunnel Blog · OpenZiti on GitHub · OpenZiti AI Enclave

Search This Blog

InstaTunnel