Bug: Self-hosted AI providers on private Docker networks are blocked

[jmbillard]

Summary

When configuring an AI provider hosted on the same Docker network (e.g. LiteLLM), Windshift refuses the connection because the resolved IP belongs to a private network.

The error shown is:

failed to connect to LLM service: Get "http://litellm:4000/v1/models": dial host resolves to a blocked IP range: 172.28.0.3 (tcp)

Environment

• Windshift running via Docker (Portainer)
• LiteLLM running in another container
• Both containers are attached to the same Docker bridge network
• The hostname (litellm) resolves correctly

Expected Behavior

Windshift should be able to communicate with AI providers running on the same Docker network in self-hosted deployments.

This is a very common setup for services such as:

• LiteLLM
• Ollama
• vLLM
• OpenAI-compatible gateways

Actual Behavior

Windshift resolves the hostname successfully but refuses to connect because the destination IP is in a private network (172.x.x.x).

The connection is blocked before any request reaches the LLM service.

Additional Context

The Docker network is working correctly. The same LiteLLM instance is successfully used by other containers such as:

• n8n
• Open WebUI

This suggests the issue is not related to Docker networking or DNS resolution, but rather to an internal restriction that blocks requests to private IP ranges.

Suggestion

For self-hosted deployments, it would be helpful to either:

• allow connections to private network addresses by default, or
• provide a configuration option to explicitly allow private IP ranges (e.g. 172.x.x.x, 192.168.x.x, 10.x.x.x) for trusted internal services.

This would enable common self-hosted AI setups while still allowing public deployments to keep stricter SSRF protections.

[stefan-ernst]

Hello, you can allow private ranges with ALLOW_LOCAL_CONNECTIONS=true

We will flip this around in the next release because it trips up a lot of people

Cheers
Stefan

[jmbillard]

@stefan-ernst It worked! Thanks again for the incredibly fast response.

While testing, I noticed one small issue: when the model configuration returns a long validation or connection error, the error message overflows outside the dialog/container. Instead of wrapping or staying within the visible area, part of the text is rendered off the right side of the screen, making it impossible to read the full message.

I'll open a separate issue for this so it's easier to track.

Thanks again!

[stefan-ernst]

Thank you for all the reports! Since this one is done, I will mark it as such