Home / Guides / Troubleshooting / Windows

Can't reach Ollama from another device — Windows Firewall

Name: LLM Configurator — GPU VRAM Checker
Author: LLM Configurator

Windows

Written by Jakub Rusinowski · Last updated September 1, 2026

Founder, LLM Configurator — AI educator & workshop leader on local LLM deployment

The error

curl: (7) Failed to connect to 192.168.1.42 port 11434 after 2004 ms: Could not connect to server

ERR_CONNECTION_REFUSED  (from a browser on another device)

Which one is it?

If you see	The cause is	Go to
It works on the PC itself but nothing external connects	Ollama is bound to 127.0.0.1, which no firewall rule can expose	Fix 1: set OLLAMA_HOST first — always first
You set OLLAMA_HOST and it still refuses	Windows Defender Firewall is blocking inbound TCP 11434	Fix 2: add a scoped inbound rule
It works on your home Wi-Fi and not on another network	The rule is scoped to the Private profile and this network is Public	Fix 2: check the profile, and leave Public alone
The rule exists and traffic is still dropped	A VPN client or third-party security suite is filtering ahead of Defender	Fix 4: check for a second firewall
You want this reachable from outside your own network	The Ollama API has no authentication of any kind	Fix 3: tunnel it — do not port-forward

When you see it

You want your phone, your laptop, or a container on another machine to use the model on your desktop. On the desktop itself http://localhost:11434 answers instantly. From anywhere else the connection is refused, and the usual reflex — open the port in the firewall — changes nothing, because the port was never the problem.

You are pointing Open WebUI, a phone app, or another PC at your desktop's IP and getting a refused connection.
You added a firewall rule for 11434 first, saw no change, and concluded the firewall is not it.
It works from a container on the same machine but not from a different device.
It worked on your home network and stopped at a coffee shop or on a work VPN.
You are about to forward port 11434 on your router because a guide suggested it.

What's actually going on

Two separate things must be true before another device can reach Ollama, and they fail in an order that misleads people. First, Ollama binds to 127.0.0.1:11434 by default — the loopback interface, which by design is not reachable from anywhere but the machine itself. While that is true, no firewall configuration on earth will let another device in, because there is nothing listening on an address they can route to. Second, once Ollama is listening on all interfaces, Windows Defender Firewall blocks unsolicited inbound connections and needs an explicit rule for TCP 11434. Readers almost always attempt the second fix first, observe no improvement, and rule the firewall out incorrectly. Do them in order and each step's effect is visible.

How to fix it

1. Bind Ollama to all interfaces with OLLAMA_HOST

Set OLLAMA_HOST to 0.0.0.0:11434 in your user environment variables — Settings → System → About → Advanced system settings → Environment Variables, or the PowerShell below — then quit Ollama from the system tray and start it again from the Start menu. Closing the window is not enough: the app reads the variable only at start. Read fix 3 before you do this on a network you do not control.

PowerShell

# PowerShell — persists for your account
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", "0.0.0.0:11434", "User")

# Quit Ollama from the system tray, relaunch from the Start menu, then:
Get-NetTCPConnection -LocalPort 11434 -State Listen |
  Select-Object LocalAddress, LocalPort, State

Did it work? LocalAddress should read 0.0.0.0 (or ::), not 127.0.0.1. While it still reads 127.0.0.1, nothing else on this page will help.

Get-NetTCPConnection -LocalPort 11434 -State Listen | Select-Object LocalAddress

2. Add an inbound firewall rule, scoped to the Private profile

Now the firewall matters. In the GUI: Windows Security → Firewall & network protection → Advanced settings → Inbound Rules → New Rule → Port → TCP → 11434, and on the profile page tick Private only. The PowerShell one-liner does the same in one step. Scoping to Private is the important part — a rule that also covers the Public profile follows you onto every untrusted network you ever join, which is exactly where you do not want an unauthenticated API listening.

⚠️ Do not tick the Public profile. Public is the profile Windows assigns to coffee-shop and hotel Wi-Fi, and this API has no authentication — a Public-profile rule exposes it to everyone on those networks.

PowerShell

# PowerShell as Administrator
New-NetFirewallRule -DisplayName "Ollama API (LAN)" `
  -Direction Inbound -Action Allow `
  -Protocol TCP -LocalPort 11434 `
  -Profile Private

# Tighter still — only one device may connect
New-NetFirewallRule -DisplayName "Ollama API (one host)" `
  -Direction Inbound -Action Allow `
  -Protocol TCP -LocalPort 11434 `
  -Profile Private -RemoteAddress 192.168.1.50

Did it work? From the other device, ask the API which models it has. A JSON list means both halves are now working.

curl http://192.168.1.42:11434/api/tags

3. Understand what you have just exposed — and prefer a tunnel Most common fix

The Ollama API has no authentication. Anyone who can reach port 11434 can list your models, run inference on your GPU, and pull new models onto your disk — a pull is an unauthenticated multi-gigabyte write to your drive. On a home LAN you trust, the scoped rule above is a reasonable trade. On a shared, office, university or public network it is not, and forwarding the port on your router is worse again. In order of how much we recommend them: an SSH tunnel, which exposes nothing and works today; a reverse proxy with authentication in front of it; or a firewall rule restricted to a single source IP. If you are unsure, use the tunnel — the client keeps talking to localhost and the traffic is authenticated and encrypted by SSH.

bash

# bash, from the CLIENT device — nothing is exposed on the network
ssh -N -L 11434:127.0.0.1:11434 you@192.168.1.42

# Then on the client, Ollama is at localhost as usual:
curl http://localhost:11434/api/tags

Did it work? With the tunnel up, the client reaches the API on its own localhost. You can then revert OLLAMA_HOST to 127.0.0.1 and delete the firewall rule entirely.

curl -s http://localhost:11434/api/tags | head -c 200

Check what fits your hardware — pick a model your host machine can serve to several devices at once
Open the VRAM checker →

4. Look for a second firewall you forgot about

If Get-NetTCPConnection shows 0.0.0.0, the Defender rule exists and traffic is still dropped, something else is filtering first. The usual suspects are a VPN client that routes or blocks LAN traffic while connected, a third-party security suite with its own firewall that supersedes Defender's rules, and — on a work laptop — a Group Policy that overrides local rules entirely. Check the network profile too: Windows silently reclassifies a network as Public after some changes, which deactivates a Private-scoped rule without telling you.

PowerShell

# PowerShell — is this network Private or Public right now?
Get-NetConnectionProfile | Select-Object Name, NetworkCategory

# Is the rule actually enabled and on the right profile?
Get-NetFirewallRule -DisplayName "Ollama API (LAN)" |
  Select-Object DisplayName, Enabled, Profile, Action

Did it work? NetworkCategory should read Private and the rule should show Enabled: True, Profile: Private, Action: Allow. A mismatch between them is your answer.

5. Remove the exposure when you are done

Worth its own step because people leave this on for months. When you no longer need remote access — the demo is over, you have moved to a tunnel, you are travelling — put the binding back to loopback and delete the rule. Two commands, and the machine stops answering to the network.

PowerShell

# PowerShell as Administrator
[Environment]::SetEnvironmentVariable("OLLAMA_HOST", $null, "User")
Remove-NetFirewallRule -DisplayName "Ollama API (LAN)"

# Quit Ollama from the tray and relaunch, then confirm:
Get-NetTCPConnection -LocalPort 11434 -State Listen | Select-Object LocalAddress

Did it work? LocalAddress reads 127.0.0.1 again and the other device gets a refused connection.

If none of this worked

If nothing is listening on 11434 at all — not even on loopback — this is the wrong page and the general connection-refused triage is the right one. If you are exposing a machine that runs headless rather than a desktop you sit at, the Linux server guide covers the operational side: reverse proxies, keeping a model warm, and the disk filling up.

Include this when you report it

Output of Get-NetTCPConnection -LocalPort 11434 -State Listen
Output of Get-NetConnectionProfile showing the network category
The exact curl command and error from the client device
Whether a VPN client or third-party security suite is installed

A model that fits most setups:

View model & requirements →

Frequently asked questions

Why does opening the firewall port not work on its own?

Because Ollama listens on 127.0.0.1 by default, and loopback is not reachable from other machines regardless of firewall state. There is nothing on a routable address for the rule to permit. Set OLLAMA_HOST to 0.0.0.0:11434 first, then add the rule.

Is it safe to bind Ollama to 0.0.0.0?

Only on a network you control. The API has no authentication, so anyone who can reach the port can run inference on your GPU and pull models onto your disk. On a trusted home LAN with a Private-profile rule it is a reasonable trade; on shared or public networks it is not.

Should I forward port 11434 on my router?

No. That publishes an unauthenticated API to the internet, where it will be found by scanners. Use an SSH tunnel, or put a reverse proxy with authentication and TLS in front of it. A VPN or Tailscale interface is a good middle ground for regular remote use.

Why does it stop working when I change networks?

Windows assigns each network a profile, and a rule scoped to Private does not apply on a network classified as Public. That is the rule working correctly. Check Get-NetConnectionProfile, and do not widen the rule to Public to make it go away.

How do I limit access to one device?

Add -RemoteAddress to the firewall rule with that device's IP, so only it may connect. Give the client a DHCP reservation first, otherwise its address changes and the rule silently stops matching. This is the narrowest option short of a tunnel.