TL;DR: Ollama ships with no authentication. Binding it to 0.0.0.0 to reach your GPU from another room puts an unauthenticated inference API on your network. This walkthrough builds a private Ollama + Open WebUI stack you can reach from anywhere without exposing port 11434. See the Twingate docs for full setup.

All the way back in September 2025 a Cisco Talos scan turned up roughly 1,100 Ollama servers with open ports on the public internet, about 20% of them actively serving models with no authentication in front of them.

Things have since scaled up: broader crawls through 2026, including work published by security researchers combining Shodan and Censys data, put the count of internet-reachable Ollama instances well into the six figures. Somewhere north of 100,000 machines, most of them running SSRF-vulnerable versions, none of them requiring so much as an API key.

Why so many exposed ports? It's the default posture. Ollama has no built-in authentication. No API keys, no user accounts, no OAuth, nothing. The moment you set OLLAMA_HOST=0.0.0.0 (the standard fix for "I want to hit my desktop GPU from my laptop") you have published an unauthenticated inference endpoint. If that machine has a public IP or a port forward, you have joined the 175,000.

This post walks through the alternative: run Ollama and Open WebUI locally, bind them to 127.0.0.1, and reach them from anywhere over Twingate.

Why the default setup is dangerous

The most common self-hosted AI story goes like this.

1. You have a workstation with a decent GPU.

2. You install Ollama, pull llama3.1 or qwen2.5-coder, and it works great locally.

Then you want to use it from your laptop in the other room, or from a coffee shop. You Google around, hit a GitHub issue, and end up here, setting Ollama to listen on all interfaces:

Now Ollama listens on every interface on the machine. If you have a firewall, only your LAN can reach it. If you added a port-forward on your router so you could hit it from the coffee shop, the entire internet can reach it.

There is no login. There is no API key. Anyone who finds port 11434 open can:

• List every model you have downloaded (GET /api/tags)

• Pull new models onto your disk (POST /api/pull) — including malicious ones

• Delete models (DELETE /api/delete)

• Run any prompt they want against your hardware (POST /api/generate)

• Burn your electricity, your GPU cycles, and — if you are on a metered connection — your bandwidth

That is before the CVEs. Ollama has shipped several remotely exploitable vulnerabilities in the last eighteen months, including CVE-2024-37032 ("Probllama"), path traversal issues in /api/pull, and denial-of-service bugs in the chat endpoint. Every exposed instance is a candidate for the next one.

For a homelab, the worst case is your GPU getting hijacked to serve someone else's chatbot. For a startup with company data flowing through prompts, the worst case is a lot worse.

How do you expose Ollama safely?

You don't. You keep Ollama bound to 127.0.0.1 and put an authenticated access layer in front of it.

Twingate acts as an identity-aware broker: your client authenticates to your identity provider, Twingate authorizes the connection against a policy, and only then does traffic reach the loopback interface on your Ollama host. Port 11434 stays closed on the public internet. No 0.0.0.0 bind, no port forward, no reverse proxy on a VPS, no Caddy-with-basic-auth workaround.

The rest of this post is the walkthrough.

Architecture overview

Here is what we are building:

• Ollama on the GPU host, bound to 127.0.0.1:11434. Nothing outside the machine can reach it directly.

• Open WebUI on the same host, bound to 127.0.0.1:3000. Talks to Ollama over loopback.

• Twingate Connector running as a Docker container on the same host. Outbound-only connection to the Twingate Controller. No inbound firewall rules.

• Twingate Client on your laptop, phone, iPad. Authenticates to your IdP (Google, Microsoft, Okta, GitHub, whatever you use).

• Resources defined in the Twingate admin console for ollama.home and webui.home (or any private DNS name you want), pointing at the loopback addresses through the Connector.

When you type http://webui.home on your laptop, the Twingate Client intercepts the DNS query, authorizes the request against the Controller, and tunnels the traffic outbound-to-outbound through the Connector, which then hands it to 127.0.0.1:3000 on the GPU host. The GPU host never accepts an inbound connection from the internet. Port 11434 never leaves the loopback interface.

Prerequisites

Before you start:

• A machine to host Ollama. Linux is easiest; macOS and Windows work but the Connector paths differ.

• Docker installed on that machine.

• A free Twingate account. The Starter tier covers up to 5 users, which is enough for a homelab and most small teams.

• An identity provider connected to Twingate. This can be a social login, like Google, GitHub, or Microsoft. Okta, EntraID, and other major IdPs are supported on paid tiers.
  
  

Step 1: Install Ollama, bound to loopback only

On the GPU host, install Ollama:

Now the important part. Do not touch OLLAMA_HOST. By default, Ollama listens on 127.0.0.1:11434, which is what we want. If someone else on the machine already changed it, put it back:

Edit the systemd override to lock Ollama to loopback:

Add the following, then save:

[Service]

Restart and pull a model:

Confirm Ollama is only listening on loopback:

You should see 127.0.0.1:11434, not 0.0.0.0:11434 and not [::]:11434. If you see either of the last two, you are still exposed and the rest of this post cannot help you until you fix it.

Step 2: Run Open WebUI, also on loopback

Open WebUI gives you a ChatGPT-style interface in front of Ollama. Run it in Docker, bound to loopback:

Start Open WebUI listening only on 127.0.0.1:

The critical part is -p 127.0.0.1:3000:8080. Without the 127.0.0.1: prefix, Docker binds to all interfaces and you are back where you started.

Verify:

You should get an HTML response from curl and see the port bound only to loopback.

Step 3: Deploy a Twingate Connector

In the Twingate admin console, create a Remote Network (call it something like homelab-gpu). Add a Connector to that network and grab the two tokens it generates (the access token and the refresh token).

Run the Connector on the same host as Ollama:

Two things to notice. First, this container makes an outbound connection to Twingate's Controller. There are no inbound ports to open, no firewall rules to change, no port forwards to configure. Second, because the Connector runs on the same host as Ollama and Open WebUI, it can reach them at 127.0.0.1. That is the whole point.

Check the Connector went online in the Twingate admin console. Should take about ten seconds.

Step 4: Define your Resources

In the Twingate admin console, under your homelab-gpu Remote Network, add two Resources:

• Address: webui.home, port 3000

• Address: ollama.home, port 11434

These hostnames do not need to exist in real DNS. Twingate creates its own private DNS namespace for you — the Twingate Client on your laptop will intercept queries for webui.home and route them through the Connector, which resolves them to 127.0.0.1 on the GPU host.

You can use any hostname you want. Some people prefer real domains they own (webui.internal.example.com). Homelab folks tend to like .home or .lab. Either works.

Now attach a Security Policy. At minimum: require your identity provider login. If you are on a paid plan, add device posture checks and MFA. If you want to grant a coworker or family member access to Open WebUI but not the raw Ollama API, put them in a group that only has access to the webui.home Resource.

Step 5: Connect from your client

Install the Twingate Client on your laptop, phone, or tablet. Sign in with your IdP.

Open a browser and go to http://webui.home:3000. You should see the Open WebUI first-run screen. Create the admin account, point it at Ollama (http://ollama.home:11434 or http://127.0.0.1:11434 from the WebUI's own container perspective — the default OLLAMA_BASE_URL you set earlier is fine), and start chatting.

Now the fun part: turn off Wi-Fi, switch to cellular, and try again. Still works. You are hitting your GPU from anywhere in the world, over an authenticated encrypted tunnel, without a single inbound firewall rule.

Try it without the Twingate Client running. webui.home does not resolve. ollama.home does not resolve. From the perspective of anyone who is not authenticated to your Twingate account, your Ollama server does not exist.

What you've actually accomplished

Compare where you started to where you are now.

The Ollama-on-0.0.0.0 school of thought treats "reachable from my laptop" as the requirement. The real requirement is "reachable from me, and only me, from anywhere." Those are very different things, and the difference is what puts 175,000 servers on Shodan.

A note on the threat model

If you are running this at home to chat with a local model, the worst case with the default setup is embarrassing: someone finds your server, uses your GPU to run their own prompts, maybe pulls a malicious model onto your disk, maybe pivots into your LAN.

If you are running this for a startup, say, a shared inference host that engineers hit from their laptops so you are not paying OpenAI rates for every experiment, the worst case is that a prompt from a compromised laptop, or an SSRF bug in a future Ollama version, becomes a foothold into your infrastructure.

Ollama has no concept of users, so it has no concept of blast radius. Every request is trusted equally.

Zero trust flips that. The identity of the person (or agent) making the request is verified against your IdP before a single packet reaches the Ollama process. If you later want to give an AI coding agent access to the same endpoint, you can issue it a scoped Service Account, put it in its own group, and revoke it in one click when the experiment ends. None of that is possible with 0.0.0.0.

Closing

For the full walkthrough on Connectors, Resources, and Security Policies, see the Twingate documentation. If you are curious about how the outbound-only Connector architecture holds up under real-world failures, our post on how Twingate stayed online during the October 2025 AWS outage walks through the design. For the broader picture of why network-level access is the wrong primitive for modern infrastructure, SDP vs VPN is a good next read.

New to Twingate? You can use Twingate for free for up to 5 users, request a personalized demo, or reach out to the team over on the Twingate subreddit.