Connectivity Issue: Can ping the Intercept Hostname but Web UI is Unreachable (ERR_CONNECTION_REFUSED)

[cyberpolat]

Hi everyone,

I am experiencing a connectivity issue with a newly configured OpenZiti service. My goal is to provide secure access to an IP Camera Web UI for our IT department. While the Ziti tunnel seems to be working (I can ping the intercept hostname), I cannot access the actual web interface.

My Environment & Configuration:

• Controller/Router OS: Ubuntu (IP: 192.168.1.100)

• Target Device: IP Camera (IP: 192.168.2.100)

• Intercept Hostname: trial.ziti (Port: 80/443 tested)

• Identity Setup: Using a Linux Edge Router as an Egress/Hosting identity (@ana-router)

The Problem:

1. From a remote client (Windows/Mobile), I can successfully ping trial.ziti. The DNS resolves correctly to the Ziti internal IP.

2. However, when I try to access http://trial.ziti in a browser, I get an ERR_CONNECTION_REFUSED error.

3. On the Ubuntu machine acting as the hosting router, I tried running curl -I http://192.168.2.100 and it fails/times out.

4. I also cannot ping the camera's local IP (192.168.2.100) directly from the Ubuntu terminal.

Current Network State: The Ubuntu router (192.168.1.100) and the Camera (192.168.2.100) are on different subnets. I suspect a routing issue on the hosting machine or a firewall policy between these internal segments. I tried adding a static route: sudo ip route add 192.168.2.0/24 via 192.168.100.1 (my default gateway), but the camera remains unreachable from the hosting router.

Questions:

• Is it mandatory for the Hosting Identity (Egress) to have direct ping/HTTP reachability to the target IP for the Ziti service to function?

• Since Ziti is "App-embedded" or "Tunneler" based, does it require the underlying OS to have a valid route to the target subnet even if the port is "dark"?

• Are there any specific logs in ziti-edge-tunnel I should look for to debug the "Connection Refused" error at the egress point?

Any help would be appreciated!

[Crystech]

Hi there, first of all, I’m not a maintainer — just a seasoned OpenZiti user sharing experience (disclaimer).

Based on your description, there are likely a few infrastructure-level issues. Below is a structured checklist to validate your setup.

---

1) Controller Reachability (Public Access)

Your controller must be reachable from the internet.

Requirement

• Port-forward public IP → 192.168.1.100

• Forward controller ports (typically 8441 API, 8440 data plane)

Verification

https://<public_ip>:8441

You should see a JSON API response.

Purpose
Ensures Ziti Edge Clients can reach the controller to establish fabric circuits.

---

2) Edge Router Connectivity

If you used the quickstart on the same server:

Requirement

• Port-forward 10080 → 192.168.1.100:10080

• Ensure Edge Router can reach Controller data plane port

Verification

telnet <public_ip> 10080

or check router status in controller.

Purpose
Ensures Edge Clients can connect to the Edge Router and form tunnels.

---

3) Internal Network Reachability

Ensure the Edge Router can reach your internal service (IP camera).

Requirement

• 192.168.1.100 → 192.168.2.100 on ports 80 and 443

Verification

ping 192.168.2.100
telnet 192.168.2.100 80
telnet 192.168.2.100 443

Purpose
Ensures the Edge Router has direct network access to the target service.

Policies Section
———————
For simplicity : ensure Policies → Router Policies Router attributes / Role Attributes set to #all

For Service Policies:
ensure

For Bind policies:

Set:

Service Attributes   →  [ my-IP-Camera-Service ]
Identity Attributes  →  [ my-router-identities-rolename-in-identities ]

This allows the selected router identities to bind (host) the service.

You may also use:

• #routergroup for router groups

• @specific_router for binding to a specific router identity
  

  

For Dial policies:

Set:

Service Attributes   → [ my-IP-Camera-Service ]
Identity Attributes  → [ my-username-in-identities ]

This allows the specified user identity to dial (access) the service.

You may also use:

• #User_group for user groups

• @specific_user_identity for a specific user
  This concluded our Policies setup.

  Configuration

  For host.v1 configuration (since you are only hosting an IP Camera):

  Set:

  Protocol : TCP (fixed)
  Address  : <IP Camera IP address>
  Port     : Forwarding mode (to allow multiple ports, e.g. 80 and 443)
  
  

  This allows the router to forward multiple service ports to the same IP camera using a single hosted service.

  

  For intercept.v1:

  The intercept config controls what traffic is captured on the user’s laptop (via the Dial policy).

  Since trial.ziti is a non-public resolvable DNS name, Ziti will intercept requests to trial.ziti and forward them to:

  192.168.2.100
  
  

  Note:
  trial.ziti only works if your host.v1 is bound to a single fixed IP (non–address forwarding mode).
  If you are using address forwarding mode, DNS-based intercept is not supported.

Once you setup correct you should be expecting **Terminators being established in Zac **

Not sure if this will helps but well…all the best

[TheLumberjack]

Thanks to @Crystech for offering some useful debugging tips! I would add that in general, our edge logging is usually "really good" and usually helps point out the problem really quickly. Look at the logs from the client as well as the logs from the "remote" (hosting/binding) identity. The logs should help indicate what the actual issue is. Looking for "ERROR" is usually what I start with.

@cyberpolat

• Is it mandatory for the Hosting Identity (Egress) to have direct ping/HTTP reachability to the target IP for the Ziti service to function?

to "the target IP" i assume is your camera? Yes, that's % mandatory. That's "how" OpenZiti works. We tunnel the traffic from intercepted side to hosting side and then we establish an IP connection to 'whatever you told it to' (in this case your target). For "zero trust host access", with no open ports, you'd run ziti-edge-tunnel ON the machine and the target IP would be 127.0.0.1 (or ::1, or localhost, you get the idea ipv4 is generally easier imo).

@cyberpolat

• Since Ziti is "App-embedded" or "Tunneler" based, does it require the underlying OS to have a valid route to the target subnet even if the port is "dark"?

Trick question... If you're using app-embedded you have embedded an SDK into the app and the answer is "no". Tunnelers are purpose-built applications by us. They are application embedded zero trust clients but their job is specifically to offload zero trust traffic back to the underlay. They specifically are bridging classic IP-based networks to the zero trust overlay and back again. So, if you're using a tunneler, then "yes" is the answer (also sort of mentioned above)

@cyberpolat

• Are there any specific logs in ziti-edge-tunnel I should look for to debug the "Connection Refused" error at the egress point?

Mentioned above but I'd look for ERROR in the logs. You can look for connection refused but there's a whole bunch of reasons. no route to host, DNS failed, bad IP address, etc. etc. etc. I'd just find the first "error" and see if it's for the service you expect.

Having "NO TERMINATORS" like @Crystech was saying would show up on the DIAL side though. That would indicate you have messed up the policy and didn't give the hosting side BIND privs. (usually, or something like that).

ziti edge policy-advisor is very useful to diagnose those sorts of problems.

hth

[cyberpolat]

"Hi again. I believe my OpenZiti services, intercept, and host/dial settings are working correctly. I can ping the network from outside, connect to the Ziti Edge, and successfully ping the specific Ziti addresses I created in the web interface. However, I cannot access the actual web UIs. For example, when I try to open the Sangfor or camera web interfaces, I get a 'Service Unavailable' error. The network connection is there, but the web service itself isn't loading."

logs appp.zip (198 Bytes)

[cyberpolat]

"I finally solved the issue; it turns out the problem was rooted in the Service Policies and Edge Router Policies. I had forgotten to add the SAN (Subject Alternative Name) info to the Edge Router policies. Additionally, both the Router and users were defined simultaneously in the Dial and Bind settings (Identity section), which was causing a policy intersection. After fixing these configurations, the problem was completely resolved."

[TheLumberjack]

Glad to hear you figured it out. As a final FYI, OpenZiti tunnelers do not support ICMP at this time. You cannot use ping to reliably infer connectivity as you tried to do.