Connection Refused on All Services via Ziti Intercept (Windows Identities, DNS Resolved)

1

Hello OpenZiti team,

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.

Thank you!

2

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.

3

Hi Shawn,

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:

  1. Service Definition (SFTP1):

    {
  "createdAt": "2025-04-12T18:46:46.081Z",
  "id": "6AXl0qO38ZT7TMaW4JKK7h",
  "tags": {},
  "updatedAt": "2025-04-12T18:46:46.081Z",
  "config": null,
  "configs": [
    "5smIsyPMpARysip3L6dx5L",
    "7Kck6TMg1jK3OkrpMGoDxI"
  ],
  "encryptionRequired": true,
  "maxIdleTimeMillis": 0,
  "name": "SFTP1",
  "permissions": [
    "Invalid"
  ],
  "postureQueries": [
    {
      "isPassing": true,
      "policyId": "dummy invalid policy: no posture checks defined",
      "policyType": "Invalid",
      "postureQueries": []
    }
  ],
  "roleAttributes": [
    "SFTP1"
  ],
  "terminatorStrategy": "smartrouting"
}

  2. Host Configuration (SFTP1-host-config):

    {
  "createdAt": "2025-04-12T18:46:45.917Z",
  "id": "7Kck6TMg1jK3OkrpMGoDxI",
  "tags": {},
  "updatedAt": "2025-04-12T18:46:45.917Z",
  "configType": {
    "id": "NH5p4FpGR",
    "name": "host.v1"
  },
  "configTypeId": "NH5p4FpGR",
  "data": {
    "address": "0.0.0.0",
    "port": 9090,
    "forwardProtocol": true,
    "allowedProtocols": [ "tcp" ],
    "httpChecks": [],
    "portChecks": []
  },
  "name": "SFTP1-host-config"
}

  3. Intercept Configuration (SFTP1-intercept-config):

    {
  "createdAt": "2025-04-12T18:46:45.767Z",
  "id": "5smIsyPMpARysip3L6dx5L",
  "tags": {},
  "updatedAt": "2025-04-12T18:46:45.767Z",
  "configType": {
    "id": "g7cIWbcGg",
    "name": "intercept.v1"
  },
  "configTypeId": "g7cIWbcGg",
  "data": {
    "portRanges": [
      {
        "high": 9090,
        "low": 9090
      }
    ],
    "addresses": [
      "sftp1.acc.ziti"
    ],
    "protocols": [
      "tcp",
      "udp"
    ]
  },
  "name": "SFTP1-intercept-config"
}

  4. Service Policies:

    • Dial Policy (SFTP1-dial-policy):

      {
  "createdAt": "2025-04-12T18:46:46.253Z",
  "id": "OeQv19NNVlIa8v0jKP13y",
  "tags": {},
  "updatedAt": "2025-04-12T18:46:46.253Z",
  "identityRoles": [ "@72vUCrGo-M" ],
  "identityRolesDisplay": [
    {
      "name": "@mypc",
      "role": "@72vUCrGo-M"
    }
  ],
  "name": "SFTP1-dial-policy",
  "postureCheckRoles": null,
  "postureCheckRolesDisplay": [],
  "semantic": "AnyOf",
  "serviceRoles": [ "@6AXl0qO38ZT7TMaW4JKK7h" ],
  "serviceRolesDisplay": [
    {
      "name": "@SFTP1",
      "role": "@6AXl0qO38ZT7TMaW4JKK7h"
    }
  ],
  "type": "Dial"
}

    • Bind Policy (SFTP1-bind-policy):

      {
  "createdAt": "2025-04-12T18:46:46.421Z",
  "id": "5kbBtO3C9zNIlAijmma1mJ",
  "tags": {},
  "updatedAt": "2025-04-12T18:46:46.421Z",
  "identityRoles": [ "@3TVCDnHa1" ],
  "identityRolesDisplay": [
    {
      "name": "@vm",
      "role": "@3TVCDnHa1"
    }
  ],
  "name": "SFTP1-bind-policy",
  "postureCheckRoles": null,
  "postureCheckRolesDisplay": [],
  "semantic": "AnyOf",
  "serviceRoles": [ "@6AXl0qO38ZT7TMaW4JKK7h" ],
  "serviceRolesDisplay": [
    {
      "name": "@SFTP1",
      "role": "@6AXl0qO38ZT7TMaW4JKK7h"
    }
  ],
  "type": "Bind"
}

5. The Issue Recap

  • 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.

Any guidance would be greatly appreciated.

Thanks in advance,

Khalid

4

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.

Is that maybe the case?