Last updated: 2026-06-26

The short version: Ollama's default install exposes port 11434 to every device on your local network — and to the internet if your router has port forwarding or UPnP enabled. This guide shows you exactly how to audit your exposure and lock it down without breaking your workflow.

The whole point of running a local LLM is that your prompts stay on your machine. But a misconfigured Ollama setup can quietly undo that guarantee. Your neighbor's laptop, your work VPN, and in some cases the public internet can reach your local AI and query it — for free, with your compute, with your models, with full access to any system prompts you've written.

This is not a theoretical risk. Shodan and Censys both index exposed Ollama instances. Researchers have documented thousands of publicly reachable Ollama deployments, many running on residential IPs.

Let's fix yours.

Step 0: Check If You're Already Exposed

Before changing anything, audit your current state. Open a terminal and run:

```bash

Check what Ollama is listening on

lsof -i :11434

Should show: LISTEN *:11434 (bad) or LISTEN 127.0.0.1:11434 (good)

```

On Linux with ss:

```bash

ss -tlnp | grep 11434

```

If the output shows 0.0.0.0:11434 or *:11434, Ollama is accepting connections from any interface — including your Wi-Fi adapter, Ethernet port, and any VPN tunnel currently active.

To test whether the port is reachable from another machine on your network, run this from a second device (or from your router's admin interface if it supports it):

```bash

curl http://YOUR_MACHINE_IP:11434/api/tags

```

If that returns a JSON list of your installed models, you're exposed.

To check for internet exposure, use Shodan's one-shot test:

```bash

Replace with your actual public IP (run: curl ifconfig.me)

curl "https://internetdb.shodan.io/YOUR_PUBLIC_IP"

```

If port 11434 shows up in the open ports list, your Ollama instance is indexed and publicly reachable.

The Threat Model: Who Actually Faces Risk

Not all exposure is equally dangerous. Here's how to think about your actual risk level:

Home network only (no remote access, no UPnP): Moderate risk. Anyone on your Wi-Fi — guests, neighbors on a poorly segmented network, any device you've connected to your hotspot — can query your models. They can also read your model list, which reveals your interests. If you've stored system prompts with sensitive context locally, those may be accessible via the API.

Home network with UPnP enabled: High risk. UPnP can automatically punch holes in your router's firewall. Many consumer routers have this enabled by default. Ollama becomes internet-accessible.

VPS or cloud instance: Critical risk. If you're running Ollama on a DigitalOcean droplet, AWS EC2, or similar — with no firewall rules — you're fully public. Check your cloud provider's security group or firewall rules immediately.

Corporate network with VPN: High risk for data confidentiality. Your IT team can see all traffic, including your Ollama API calls from other machines. Worse, your employer's MDM software may be able to query the Ollama port if it's accessible on the VPN subnet.

Step 1: Bind Ollama to Localhost

This is the single most important fix and takes about two minutes.

On macOS (using LaunchAgent):

Ollama on macOS typically runs as a background service. Find the plist:

```bash

ls ~/Library/LaunchAgents/ | grep ollama

```

Edit it (usually ~/Library/LaunchAgents/com.ollama.ollama.plist) and add the OLLAMA_HOST environment variable:

```xml

EnvironmentVariables

OLLAMA_HOST

127.0.0.1:11434

```

If you installed via the Ollama.app GUI, you can also set this in your shell profile:

```bash

Add to ~/.zshrc or ~/.bashrc

export OLLAMA_HOST=127.0.0.1:11434

```

Then restart Ollama:

```bash

launchctl unload ~/Library/LaunchAgents/com.ollama.ollama.plist

launchctl load ~/Library/LaunchAgents/com.ollama.ollama.plist

```

On Linux (systemd):

```bash

sudo systemctl edit ollama

```

In the override editor, add:

```ini

[Service]

Environment="OLLAMA_HOST=127.0.0.1:11434"

```

Then reload:

```bash

sudo systemctl daemon-reload

sudo systemctl restart ollama

```

Verify the fix:

```bash

lsof -i :11434

Should now show 127.0.0.1:11434, not *:11434

```

Try querying from another machine — it should now time out or refuse connection.

Step 2: Add a Reverse Proxy With Authentication

Binding to localhost stops network exposure, but if you're running Ollama on a server you SSH into, or if you want to expose it selectively to your home network with authentication, a reverse proxy is the right approach.

Caddy is the simplest option — it handles HTTPS automatically and has a clean config syntax:

```bash

Install Caddy (varies by OS — see caddyserver.com/docs/install)

Create /etc/caddy/Caddyfile:

:8080 {

basicauth {

# Generate hash: caddy hash-password

youruser JDJhJDE0JEVTTkEw...

}

reverse_proxy localhost:11434

}

```

Now Ollama is only accessible at localhost:8080 with HTTP Basic Auth. Remote clients need a username and password — not just network access.

For Open WebUI or other frontends that need to reach Ollama, point them at http://localhost:8080 with the credentials.

Step 3: Firewall Rules as a Backstop

OS-level binding is your first defense. Firewall rules are your second. Configure both — defense in depth.

macOS (pf or the built-in Application Firewall):

The macOS Application Firewall doesn't filter by port natively, so use pf for port-level rules:

```bash

/etc/pf.conf addition — block port 11434 from all external interfaces

block in quick on en0 proto tcp to any port 11434

block in quick on en1 proto tcp to any port 11434

```

Replace en0/en1 with your actual interface names (ifconfig | grep '^en').

Linux (ufw):

```bash

sudo ufw deny 11434

Or, to allow only from a specific subnet:

sudo ufw allow from 192.168.1.0/24 to any port 11434

sudo ufw deny 11434

```

Linux (iptables directly):

```bash

sudo iptables -A INPUT -p tcp --dport 11434 ! -s 127.0.0.1 -j DROP

```

Step 4: Secure Remote Access With a VPN (Not Port Forwarding)

The most common reason people expose Ollama to the network is legitimate: they want to query it from their laptop while traveling, from a tablet at a coffee shop, or from their office while the GPU stays home.

The wrong answer is port forwarding port 11434 through your router to the public internet. Even with IP allowlisting, you're adding real attack surface with no encryption in transit.

The right answer is a VPN that lets you access your home network as if you were local — without exposing any ports publicly.

Proton VPN has a feature called Secure Core combined with their Port Forwarding / VPN setup, but the more relevant tool for this use case is pairing ProtonVPN with their custom DNS to reach devices on your home network. More practically: use Proton VPN on your home router (they support DD-WRT, OpenWRT, and pfSense) to make your home an encrypted VPN endpoint.

When you're traveling, connect to your home Proton VPN endpoint. Your laptop appears to be on your home network. You can reach localhost:11434 (or the LAN IP of your AI box) — encrypted end-to-end, no ports forwarded, no exposure.

Affiliate Disclosure: This article may contain affiliate links. If you make a purchase through these links, we may earn a small commission at no extra cost to you. We only recommend products we genuinely believe in. This helps support our work and allows us to continue providing free content.

Practical setup:

Create a Tresorit Tresor (their term for an encrypted vault)
Point your AI scripts to save outputs to that folder
Store your system prompt files there instead of in your home directory
Any AI-generated analysis you want to share uses Tresorit's secure link sharing — recipient gets a unique link, files stay encrypted in transit

For local-only use where you're not syncing to the cloud, Cryptomator (open source) gives you the same folder-level encryption without cloud storage.

Step 6: Know When Not to Use Local AI

A locked-down Ollama is excellent for sensitive work. It is overkill — and sometimes a poor experience — for general research.

If you're looking up "PostgreSQL index types," "React state management patterns," or "best practices for API rate limiting," there's no confidentiality reason to run local inference. You're burning GPU time and time-to-response for zero privacy benefit.

For non-sensitive technical research, Perplexity AI is a significantly better research experience than querying a local LLM: it searches the live web, cites sources, and gives you current information that a locally-running open-weight model can't match.

The mental model: if the query contains anything you wouldn't put in a public Stack Overflow post, route it to local Ollama. If it's generic technical research, Perplexity gets you better answers faster. This hybrid approach is what we cover in depth in our AI compartmentalization workflow guide.

The Hardened Ollama Checklist

Run through this before calling your setup secure:

[ ] lsof -i :11434 shows 127.0.0.1:11434, not *:11434
[ ] OLLAMA_HOST=127.0.0.1:11434 is set in your systemd unit or LaunchAgent plist
[ ] Firewall rule blocks external access to port 11434 as a backstop
[ ] If you need remote access: using a VPN, not port forwarding
[ ] Reverse proxy with authentication if exposing to a local subnet
[ ] System prompts and sensitive outputs stored in an encrypted folder
[ ] Public IP checked against Shodan — port 11434 not listed
[ ] UPnP disabled on your router (check router admin → Advanced → UPnP)

One More Thing: Check Your Router

UPnP (Universal Plug and Play) is enabled by default on most consumer routers. It allows devices on your network to automatically open ports in your router's firewall — without your knowledge or approval.

An Ollama process that requests a port forward via UPnP would silently become internet-accessible. Most versions of Ollama don't do this, but other software on your machine might open a path that makes it reachable indirectly.

Log into your router's admin panel (usually 192.168.1.1 or 192.168.0.1) and find the UPnP setting. Disable it. If anything breaks, you'll know what depended on it — and can re-enable selectively.

Summary

Running a local LLM is a meaningful privacy upgrade over cloud AI — but only if the local setup is actually private. The defaults don't guarantee that. A twenty-minute hardening pass covering localhost binding, firewall rules, and encrypted output storage puts you in a materially better position.

The goal isn't paranoia. It's making sure the privacy promise of "runs on your machine" is actually true end to end.

Start receiving our weekly private AI setup guide — practical hardening techniques, model recommendations, and workflow templates for privacy-conscious engineers. No tracking pixels. Unsubscribe anytime.

Subscribe to the PrivateAI Weekly →

Have a setup question or a hardening tip we missed? The checklist above is a living document — we update it as Ollama releases new versions.