I’m running into a persistent issue using OpenZiti where all service connections fail with “Connection refused” when accessed through the intercept address, despite successful setup.
⸻
Deployment Overview
• Ziti Hosting:
Deployed via the official Docker Compose Quickstart (docker-compose.yml) on a Linux VPS (Ubuntu).
All containers are running and marked as healthy:
• ziti-controller
• ziti-edge-router
• ziti-fabric-router-br
• ziti-edge-router-wss
• ziti-console
• web-test-blue, etc.
• Edge Clients:
Two Windows OS machines running Ziti Edge Client with successful enrollment.
⸻
Identity and Service Setup
• Identity 1 (mypc):
Acts as the client, trying to access services via intercepts like:
sftp1.acc.ziti:9090
• Identity 2 (VM):
Acts as the host, where actual services (SFTP, HTTP, etc.) are bound to 127.0.0.1:9090 (also tried 0.0.0.0).
• Service Example (sftp1):
• Intercept Address: sftp1.acc.ziti:9090
• Host Binding: 127.0.0.1:9090
• Protocols: TCP
• Assigned Host Config: VM
• Assigned Intercept Config: mypc
• Service Policy: Both identities are correctly assigned to their respective configs.
• DNS Resolution:
I have already manually resolved DNS on both Windows machines using the C:\Windows\System32\drivers\etc\hosts file to point sftp1.acc.ziti to 127.0.0.1.
ping sftp1.acc.ziti resolves correctly on both.
⸻
The Problem
When trying to connect to any service (SFTP, HTTP, FTP, etc.) from the client (mypc) via the intercept like:
sftp sftp1.acc.ziti -P 9090
I always get:
Network error: Connection refused
This happens for all intercepts, regardless of port:
• 9090 (SFTP)
• 80 (HTTP)
• 443 (HTTPS)
• 21 (FTP)
⸻
What I’ve Verified
• Ziti Edge Client shows both identities online.
• Controller and routers are marked ONLINE in ziti edge list edge-routers.
• The services are accessible locally from VM via localhost:9090 and other ports.
• DNS resolves properly via hosts file.
• Identity roles and service policies were set correctly.
• Restarted all Ziti services and clients.
⸻
What I Need Help With
• Is this a Windows-specific routing issue?
• Does the service binding need to be on a public interface instead of 127.0.0.1?
• Is there something wrong with how the host and intercept configs are applied for Windows OS?
• How can I confirm that traffic is actually being passed through the overlay and reaching the host?
Any guidance or debugging tips would be greatly appreciated.
You should not create hostname mappings in your hosts file. Ziti Desktop Edge for Windows sets up the Windows so that hostnames in your intercept configurations are resolved by the tunneler process itself. Btw the resolved addresses will look like "100.64.0.3" or similar assuming you are using the default ZDEW settings.
Mapping the hostnames to 127.0.0.1 (or any address at all actually) will either prevent the connections from being seen by ZDEW or prevent ZDEW from being able to figure out which service the connection is associated with.
Thank you for your detailed response. I’d like to clarify a couple of things about my setup and share my service configuration in full—this will help illustrate the issue I’m encountering.
My Hosts File Setup
In my Windows hosts file (located at C:\Windows\System32\drivers\etc\hosts), I only have the following entry:
ziti-edge-controller
I did not add any mapping for the intercept hostname (e.g., “sftp1.acc.ziti”). In my environment, the Ziti Desktop Edge client is responsible for resolving intercept names internally (which, in a proper setup, should yield an IP in the 100.64.x.x range). For example, when I run a ping:
`ping sftp1.acc.ziti`
it returns something like 100.64.0.8. So the DNS resolution for intercept names is being handled by Ziti as expected.
My Service Setup for “SFTP1”
Here are the detailed JSON configurations for my service:
When I try to connect from my client (mypc) using:
sftp -P 9090 tester@sftp1.acc.ziti
I get:
ssh: connect to host sftp1.acc.ziti port 9090: Connection refused
Connection closed
This “connection refused” error occurs for SFTP (port 9090) as well as for other protocols (HTTP on 80, HTTPS on 443, FTP on 21).
I've verified that:
The Ziti Edge Client on both mypc and VM shows the identities as online.
The service is accessible locally on the VM via localhost (port 9090).
DNS resolution (via Ziti’s internal mechanism) for “sftp1.acc.ziti” works correctly (ping returns an IP in the 100.64.x.x range).
6. What I Suspect Needs Fixing
Based on the above:
Service configuration issue:
The service definition includes "permissions": ["Invalid"] and a dummy posture query. This may prevent the controller from fully "hosting" the service (i.e. creating a proper terminator) even though the configuration is accepted in part.
Terminator creation:
Without a valid service host configuration, the Ziti fabric isn’t establishing the terminator that would forward intercepted connections to the SFTP service.
If every single port is getting rejected immediately, this feels to me like the offload is somehow incorrectly configured.
You also mention that you only have ziti-edge-controller in your hosts file, that makes me think you are using the complex docker compose example that we have, is that true? You also need to make sure you have ziti-edge-router in your hosts files too or your client won't be able to connect to a router.
Thank you so much for jumping in — I really appreciate the time and support from the team.
Yes, I’m indeed using the official complex docker-compose.yaml from the OpenZiti Quickstart (the one that includes ziti-controller, ziti-edge-router, ziti-edge-router-wss, etc.). You are absolutely right — I had only added ziti-edge-controller to the hosts file on my Windows client machine, not ziti-edge-router, and I now understand how that might have caused connectivity issues from the client to the router.
But unfortunately, the issue still persists. I’m still getting:
ssh: connect to host sftp1.acc.ziti port 9090: Connection refused
I’ve shared full service configurations, and it seems the permissions: ["Invalid"] and dummy posture checks may also be causing the host (VM) to fail at creating a terminator for the service.
Would It Be Possible to Schedule a Short Troubleshooting Session?
I’ve spent quite a bit of time trying to resolve this, and I’d be super grateful if you could spare 15–20 minutes to join me on a quick call or session (Zoom, Teams, or whatever you prefer). That would help clear things up much faster — especially given how close the config seems to be.
If it’s feasible, I can align with your schedule anytime that suits you. Please let me know
Thank you so much for your continued support and insights.
I’ve carefully reviewed the guidance shared by both you and @scareything (Shawn), and I’ve gone ahead and corrected the host.v1 config to use 127.0.0.1 instead of 0.0.0.0 as suggested. I also double-checked that no mappings exist in my hosts file for intercept addresses like sftp1.acc.ziti.
⸻
Update on Testing After Fixing Host Binding to 127.0.0.1
Here’s what I did after making the suggested changes:
host.v1 now uses: "address": "127.0.0.1" "port": 9090
No static DNS mappings for intercept names like sftp1.acc.ziti in the Windows hosts file (confirmed).
DNS resolution is occurring internally through ZDEW as expected (e.g., ping sftp1.acc.ziti returns something like 100.64.x.x).
Ziti tunnel interface (ziti-tun0) is up with 100.64.0.1 on both client and host machines.
Test Results
Source
Command
Result
mypc
sftp -P 9090 tester@sftp1.acc.ziti
Connection refused
vm
sftp -P 9090 tester@sftp1.acc.ziti
Could not resolve hostname
Note: By using the vm Ethernet0 IP or the vm hosname I test the SFTP service on 9090 it was working very will.
Additional Notes
Ziti Edge Client shows both identities (mypc, vm) as online.
ziti edge list edge-routers confirms all routers are ONLINE.
Service is reachable via localhost:9090directly on the host VM.
Wireshark shows no packets arriving at port 9090 when accessed via intercept.
ziti-tun0 interface has no gateway and uses 100.64.0.2 as DNS on both Windows machines (set manually from the tunnel config).
Remaining Issue
Despite all configurations being correct and intercept resolution working, I still get connection refused from the client side (mypc), and the host side (vm) cannot resolve sftp1.acc.ziti at all.
Request for Assistance
If possible, I would truly appreciate if you could spare a bit of time to jump on a quick session (Zoom/Google Meet or even Discord) and walk through this with me. I’ve spent considerable time debugging and collecting logs (available if needed), but I think having a second set of eyes could really help.
Let me know if you’re available and I’ll accommodate your schedule.
in Both vm and mypc this is the hosts file content
# Copyright (c) 1993-2009 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
# 102.54.94.97 rhino.acme.com # source server
# 38.25.63.10 x.acme.com # x client host
# localhost name resolution is handled within DNS itself.
# 127.0.0.1 localhost
# ::1 localhost
194.163.169.204 ziti-edge-controller
194.163.169.204 ziti-edge-router
then i go to the ziti-tun0 interface and i add the ip address DHCP Becouse it was empty and not as DHCP as will.
and the DNS server in ziti-tun0 interface i add 100.64.0.2 se it was empty as the tunnel config show Becouse it was empty and not as DHCP as will..
C:\Users\Admin>sftp -P 9090 tester@SFTP1.acc.ziti
C:\\Windows\\System32\\OpenSSH\\ssh.exe: Could not resolve hostname sftp1.acc.ziti: No such host is known.
Connection closed
Test from mypc (client):
PS C:\Users\Caval> sftp -P 9090 tester@SFTP1.acc.ziti
ssh: connect to host sftp1.acc.ziti port 9090: Connection refused
Connection closed
PS C:\Users\Caval>
Any help regarding this issue would be appreciated. I chose this as my master's project because it's well-documented and has good support, but now I feel like I've hit a wall
Hi @KHALID, we do our best to support people who show up in the forums. We will answer the best we can, when we can. I understand you've hit a wall and that's frustrating but your problem isn't one where we can offer two or three sentences and give you a solution. SFTP should hopefully be a pretty straightforward setup.
does the service show up in the tunneler / client logs? You're using the ZDEW, does your identity have the SFTP1 service assigned to it?
The Test VM looks like it's a windows machine too, does it also show you that it has the SFTP1 service?
The easiest way to check this is probably to use the ziti cli, can you run policy-advisor? Replace mgmt with SFTP1 (or whatever the service name is). For example, here's output from my network:
ziti edge policy-advisor services mgmt -q
OKAY : tod (1) -> mgmt (1) Common Routers: (1/1) Dial: Y Bind: N
OKAY : ip-172-31-47-200-edge-router (1) -> mgmt (1) Common Routers: (1/1) Dial: Y Bind: Y
OKAY : forwarder (1) -> mgmt (1) Common Routers: (1/1) Dial: Y Bind: N
See how each has at least 1 "Common Router", there is one identity that has Bind: Y permission, and there are two identities with Dial: Y permission? We need to make sure we see that.
If you have an identity Bind'ing (the test vm I assume) and you have a dialing identity, then make sure both identities are connecting to that router.
You had entered a hosts entry for your local ZDEW to connect to your docker compose overlay. Where is that overlay? Does the Test VM have connectivity to that router or do you need to figure out a way to get the VM to connect to the overlay?
You can also make sure the Test VM is properly binding the service by running (again replace mgmt with your service name):
ziti edge list terminators 'service.name="mgmt"'
After that, look at the logs from the client and the logs from the server. Make sure you see logs on the client indicating it is intercepting traffic and make sure you see logs on the server indicating it's receiving traffic.
Have a look a those logs too and see if there are any helpful messages, there often are useful logs helping you to know what went wrong.
After weeks of investigation and community support, I’m happy to share that our OpenZiti setup is now fully operational, and we were able to complete our master’s project demonstration successfully.
⸻
Root Cause
The issue turned out to be subtle but critical:
Ziti Desktop Edge for Windows & MAC OS (ZDEW) had DNS intercept disabled by default showing add DNS value is false, preventing intercept hostnames like sftp1.acc.ziti from resolving correctly.
As a result, even though all identities, services, and policies were properly configured, the tunneler was unable to route traffic, leading to “Connection refused” errors on all protocols Or Domain cannot be resolved (SFTP, HTTP, FTP…).
⸻
Final Resolution Steps
Here’s what resolved the issue:
1. Uninstalled ZDEW completely
2. Rebooted both client and host machines
3. Reinstalled ZDEW cleanly
4. Enabled DNS Intercept in ZDEW settings
5. Removed all static entries from the hosts file except the ones mapping:
• ziti-edge-controller
• ziti-edge-router
to the VPS public IP
6. Validated config and connectivity using:
• ziti edge list terminators 'service.name="SFTP1"'
• ziti edge policy-advisor services SFTP1 -q
After these steps, intercept resolution returned IPs in the 100.64.x.x range, and tunneled access to the service started working immediately.
⸻
Acknowledgments
Huge thanks to:
• @TheLumberjack and @scareything for consistently guiding the debugging process
• The entire OpenZiti community for sharing practical insights
• Mr. Samuel Adewole, Founder of Digital Security Insights and Co-Founder of CM & Co Consulting Group AB, who kindly emailed me a full troubleshooting sequence from scratch. His support helped us identify the offload misconfiguration and complete our work on time.
⸻
This experience reminded us how Zero Trust networking can be both powerful and complex, and how the OpenZiti community makes the journey worth it.
— Khalid Shalwan Founder and Chief Executive Officer (CEO) of Lubab CIT Company Ltd.
Connection refused
Additional Notes
Remaining Issue