Http_server_id variable for http hello world example

Hi there,
I‘m really new to OpenZiti and currently trying to get the hello world http example to work:
https://openziti.github.io/ziti/quickstarts/services/host-access.html
Which value should the variable ${http_server_id} contain? I can’t seem to find where it was defined or which value it should have

I have followed all the steps and replaced the variable with http-server which doesn’t seem to work.
The client says connection refused when trying to the respective port.

Thanks!

Hi @dmuensterer, welcome to OpenZiti, nice to have you in the community!

I can’t believe that wasn’t explained in more detail! I made an issue to track that here: explain http_server_id better on host-access · Issue #169 · openziti/ziti-doc · GitHub

Right now, when you run ziti edge list identities with your CLI, can you show me what you get back? The “id” we need is in that response. For example when I run it, my “id” is: GUk3rc.7u

ziti edge list identities 'name contains "http-server"'
╭───────────┬─────────────┬──────┬────────────╮
│ ID        │ NAME        │ TYPE │ ATTRIBUTES │
├───────────┼─────────────┼──────┼────────────┤
│ GUk3rc.7u │ http-server │ User │            │
╰───────────┴─────────────┴──────┴────────────╯

If you jsut want to set the variable you can use the -j flag and jq and you can run:

http_server_id=$(ziti edge list identities 'name contains "http-server"' -j | jq -r .data[].id)

echo $http_server_id
GUk3rc.7u

That help?

1 Like

Wow, that was a fast reply!
Gotcha, will try that out asap.
One more question, hope that’s fine:
In the linked study it‘s written that „admins enjoy agentless access“ - does that mean there’s a way to access web applications even without a JWT or certificate? Or is the meaning here that there’s just no need for a client in addition to the tunneler?
If no, are there any plans to offer authentication via e.g. AzureAD, Okta without the need for an agent?
I currently enjoy having my Webapp protected behind CloudFlare‘s ZT network and being able to
access it from any device with a browser.

Don't forget to hit that like button and subscribe GitHub star! :slight_smile: We aim to please!

From the OpenZiti perspective - this a "non-starter". You will always need to provide some kind of strong identity to the network before connecting. "Authorize before connect" is a core tennat of the zero trust model. You cannot access the network without an x509 certificate (the strong, cryptographically secure identity we use currently).

It's the latter, this: "Or is the meaning here that there’s just no need for a client in addition to the tunneler?"

What that means is the developers have taken an OpenZiti and embedded it into their application. By doing that, they get the benefit of OpenZiti, without adding complexity to their user base. OpenZiti still uses an X509 certificate, but it's handled by the SDK, wrapped in the Ohka app. So the Ohka app with the OpenZiti SDK baked into it is able to access things without the need to install an agent, what we would call an "OpenZiti Tunneler".

From that doc:

Ohka’s developers use OpenZiti SDKs to embed private networking into their custom-built apps in a few lines of code. For other use cases, they use the OpenZiti Tunnelers which are easy to use for desktop and mobile applications that consume data from datacentres or cloud environments.

We are very close to releasing "browZer", an agentless/installless, mechanism for boostrapping zero trust in your browzer, allowing you to access HTTP services in a seamless way. It will work very much like you're describing. So yes, it's very much in the works and should be landing soon. You can read about it on the introducing browzer blog article that went live recently:

https://openziti.io/introducing-openziti-browzer

[small edit around 'what' browzer is]

1 Like

Thank you very much! Already starred on GitHub!
I think you have a bright future ahead, love everything I’ve seen so far!

1 Like

Nice! That’s what’s up! We appreciate the kind words. Make sure to tell all your friends too ! :smiley: Let us know if there’s anything else we can help with. Cheers!

1 Like

Hm, as the Ziti noob that I am I can’t figure out why my setup isn’t working.
I thought I followed all the steps in the example
Here’s my network:
Identities:

╭────────────┬─────────────────────────────────┬────────┬─────────────╮
│ ID         │ NAME                            │ TYPE   │ ATTRIBUTES  │
├────────────┼─────────────────────────────────┼────────┼─────────────┤
│ 5j0lBzEOw  │ myhostname-edge-router │ Router │        │
│ Ids3AoLZvU │ log-client                      │ User   │ log-clients │
│ clY0ioLLvU │ log-server                      │ User   │             │
│ sjlk8JhLd  │ Default Admin                   │ User   │             │
╰────────────┴─────────────────────────────────┴────────┴─────────────╯

Services:

╭────────────────────────┬─────────┬────────────┬─────────────────────┬────────────╮
│ ID                     │ NAME    │ ENCRYPTION │ TERMINATOR STRATEGY │ ATTRIBUTES │
│                        │         │  REQUIRED  │                     │            │
├────────────────────────┼─────────┼────────────┼─────────────────────┼────────────┤
│ 2JC6jdGbr6FdGMEIEoXhSS │ log.svc │ true       │ smartrouting        │            │
╰────────────────────────┴─────────┴────────────┴─────────────────────┴────────────╯

Service Configurations:

 ────────────────────────┬──────────────────┬──────────────╮
│ ID                     │ NAME             │ CONFIG TYPE  │
├────────────────────────┼──────────────────┼──────────────┤
│ 1Ed9BzKj50UyoRqQdS0JfX │ log.host.v1      │ host.v1      │
│ 6QIdrQprKbv3Vdt6GVMQbR │ log.intercept.v1 │ intercept.v1 │
╰────────────────────────┴──────────────────┴──────────────╯

Service Policies:

╭────────────────────────┬─────────────────┬──────────┬───────────────┬────────────────┬─────────────────────╮
│ ID                     │ NAME            │ SEMANTIC │ SERVICE ROLES │ IDENTITY ROLES │ POSTURE CHECK ROLES │
├────────────────────────┼─────────────────┼──────────┼───────── ──────┼────────────────┼─────────────────────┤
│ 3b2d1xGGOUO4wQT6QD8fOE │ log.policy.bind │ AllOf    │               │ @log-server    │                     │
│ 6JeuGMhuxqPKY96BZJWBEV │ log.policy.dial │ AllOf    │               │ #log-clients   │                     │
╰────────────────────────┴─────────────────┴──────────┴───────────────┴────────────────┴─────────────────────╯

Both, server and client tunneler are connected, but when accessing 127.0.0.1:4000 which should be bound, I get a “Connection refused”

Looks like you’re falling into a TCP/layer4 trap. 127.0.0.1:4000 will never route over ziti. That IP is very special. I don’t see your config details - I’d like to know what you used for the intercept.v1 config. Can you share that?

For example, in that “first service:” demo - you would issue a curl to http.ziti: curl http.ziti. Under the hood, http.ziti will be a DNS request that is intercepted by the ziti tunneler, turned into an ip address in the 100.64.x.x range, and your http request will go to 100.64.0.3:80. 127.0.0.1 is not going to work with ziti.

You could ‘dig’ at your intercept (presumably it is ‘log.server.ziti’) and get the IP if you want but you shouldn’t rely on that IP. It can change depending on how many services you have configured.

Can you share the intercept.v1 you used? or try to access your service using whatever that hostname was and see how that works?

I also don’t see any service roles on your service policy - that’s a problem too:

clint_private_aws: ~$ ziti edge list service-policies 'name contains "http"'
╭────────────┬──────────────────────────┬──────────┬───────────────┬──────────────────────────────┬─────────────────────╮
│ ID         │ NAME                     │ SEMANTIC │ SERVICE ROLES │ IDENTITY ROLES               │ POSTURE CHECK ROLES │
├────────────┼──────────────────────────┼──────────┼───────────────┼──────────────────────────────┼─────────────────────┤
│ GjMms8B7aR │ http.sample-dialing      │ AllOf    │ @http.sample  │ @http.sample.client          │                     │
│ WYU8MpB7D  │ simple-http-service-bind │ AllOf    │               │ @server.id                   │                     │
│ XENx8WZ7aR │ simple-http-service-dial │ AllOf    │               │                              │                     │
│ frorcC.7Ig │ http.policy.bind         │ AllOf    │ @http.svc     │ @ip-172-31-42-64-edge-router │                     │
│ nXjTe5cX6  │ http.ziti.policy.dial    │ AllOf    │ #devservices  │ #devendpoints                │                     │
│ xSjVCC97I  │ http.policy.dial         │ AllOf    │ @http.svc     │ #http-clients                │                     │
│ yXMmr8B7DR │ http.sample-binding      │ AllOf    │ @http.sample  │ @http.sample.server          │                     │
╰────────────┴──────────────────────────┴──────────┴───────────────┴──────────────────────────────┴─────────────────────╯

i have a bunch in my server :slight_smile: from all my testing and whatnot

Thanks! Okay so looks like I had a major missunderstanding here. I didn’t know I mandatorily needed to create an own hostname but thought I could just use 127.0.0.1.
Now I understand.

However it still doesn’t work, not sure what I’m missing.
my service-policy looks like this:

╭────────────────────────┬─────────────────┬──────────┬───────────────┬────────────────┬─────────────────────╮
│ ID                     │ NAME            │ SEMANTIC │ SERVICE ROLES │ IDENTITY ROLES │ POSTURE CHECK ROLES │
├────────────────────────┼─────────────────┼──────────┼───────────────┼────────────────┼─────────────────────┤
│ 35hNf3OftxgMNm0cQASCvh │ log.policy.bind │ AllOf    │ @log.svc      │ @log-server    │                     │
│ 6SWG7DWs4QU9bJMqICz1H6 │ log.policy.dial │ AllOf    │ @log.svc      │ #log-clients   │                     │
╰────────────────────────┴─────────────────┴──────────┴───────────────┴────────────────┴─────────────────────╯

I created intercept.v1 like this:

ziti edge create config log.intercept.v1 intercept.v1 '{"protocols":["tcp"],"addresses":["log.ziti"], "portRanges":[{"low":80, "high":80}]}'

Yeah, it’s a killer feature (imo) of OpenZiti - being able to make up any old DNS name and use it :slight_smile: You must either use an IP address or a DNS name, but for my money the DNS entry is better.

Now you’re at the point where you should probably look at the client (dial side) logs and the ‘server’ (bind side) logs.

One of them will give you an indication of what’s going wrong. Also, let’s check your ‘bind’ config and make sure it’s terminating where you expect it to.

Thanks!
This is how I created the bind config: ziti edge create service-policy log.policy.bind Bind --service-roles ‘@log.svc’ --identity-roles “@7U5nuY5-U

Server side logs don’t show anything suspicious, client side does however:

[2022-09-28T23:17:24.727Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:17:24.727Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 76584 ms (attempt = 12)
[2022-09-28T23:18:41.313Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:18:41.313Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 43154 ms (attempt = 13)
[2022-09-28T23:19:24.471Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:19:24.471Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 77471 ms (attempt = 14)
[2022-09-28T23:20:42.126Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:20:42.126Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 34713 ms (attempt = 15)
[2022-09-28T23:21:16.843Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:21:16.843Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 73782 ms (attempt = 16)
[2022-09-28T23:22:30.626Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:22:30.626Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 31064 ms (attempt = 17)
[2022-09-28T23:23:01.693Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-28T23:23:01.693Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 135103 ms (attempt = 18)

Any ideas?

looks like the client side isn’t connected to your edge router. what is the edge router’s advertised address? your clients both will need to connect to your edge router over port 8442 (if you used the quickstart).

open the router’s config file, find this section:

listeners:
# bindings of edge and tunnel requires an "edge" section below
  - binding: edge
    address: tls:0.0.0.0:8442
    options:
      advertise: ec2-18-188-201-183.us-east-2.compute.amazonaws.com:8442
      connectTimeoutMs: 1000
      getSessionTimeout: 60s

is the ‘advertise’ host/port available from the client?

i use openssl to test - for example in my edge router shown above, I run:

openssl s_client -connect ec2-18-188-201-183.us-east-2.compute.amazonaws.com:8442

(which you can try too if you want)

1 Like

That seems to be the problem. Somehow the advertised port is 8441 and not 8442.
Not sure where how this went wrong but I can’t find where to change it on the client side. Im using the Mac tunneler for testing.

1 Like

Great, so you have your first service working as expected?

8441 is the controller API when following the quickstart. It’s how edge devices authenticate to the network to gain a session and how edge devices obtain the list of services they are authorized to access etc.

8442 is the data plane port. It’s where the edge devices will connect to the edge routers to send data across the zero trust overlay.

Thanks, not yet. Somehow when I create a JWT, it contains hostname:8441 instead of 8442.
I assume I messed up somewhere when setting up the environment variables.

So… The JWT will contain 8441. That’s how your edge device will be able to send a message (a CSR) to the controller to generate/issue/sign your x509 certificate… So port 8441 needs to be open for starters (and 8442 for the data plane)

Once the certificate is issued, during the enrollment process (read up on the process on this 5-part blog post Bootstrapping Trust Part 1), you’ll have your strong identity.

When the edge router comes online, it will read its config and tell the controller, “hey, i’m edge enabled and i am listening on my-edge-router-host:port”.

Then when the edge device authenticates to the controller, the controller will say, “Hey edge device. You have n edge routers and here is the host:port to contact. Send that strong identity we just created over to these edge routers so you can be ‘on the overlay network’”.

That’s clearly a huge oversimplification - but that’s the gist. That help?

As long as you haven’t modified the config files manually - everything ‘should’ be fine for you. Usually it’s the web ACL or local firewalld rules that catch people.

I would start by issuing openssl commands to both 8441 and 8442 and verify they succeed:

openssl s_client -connect your-vps-host-name:8441
openssl s_client -connect your-vps-host-name:8442

You should see a replies “immediately”… not timeouts

Ok, checked, that works! However I still can’t get a connection:

[2022-09-29T14:18:30.499Z]    INFO ziti-sdk:channel.c:231 new_ziti_channel() ch[0] (hostname-edge-router@tls://hostname:8442) new channel for ztx[0] identity[log-client]
[2022-09-29T14:18:30.499Z]    INFO tunnel-cbs:ziti_tunnel_ctrl.c:797 on_ziti_event() ztx[log-client] added edge router hostname-edge-router@tls://hostname:8442@hostname
[2022-09-29T14:18:30.499Z]    INFO ziti-sdk:channel.c:743 reconnect_channel() ch[0] reconnecting NOW
[2022-09-29T14:18:30.506Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-29T14:18:30.506Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 3470 ms (attempt = 1)
[2022-09-29T14:18:30.786Z]    INFO tunnel-cbs:ziti_tunnel_cbs.c:411 new_ziti_intercept() creating intercept for service[log.svc] with intercept.v1 = {"addresses":["log.ziti"],"portRanges":[{"high":80,"low":80}],"protocols":["tcp"]}
[2022-09-29T14:18:30.786Z]    INFO tunnel-cbs:ziti_dns.c:269 new_ipv4_entry() registered DNS entry log.ziti -> 100.64.0.10
[2022-09-29T14:18:30.786Z]    INFO tunnel-cbs:ziti_tunnel_ctrl.c:686 on_service() starting intercepting for service[log.svc]
[2022-09-29T14:18:30:789Z]    INFO PacketTunnelProvider:ZitiTunnelDelegate.swift:219 tunnelEventCallback() ZitiTunnelEvent: <CZiti.ZitiTunnelServiceEvent: 0x14311ee30>
   identity: log-client:"UzJs6Rl0s"
   status: 
   removed: (0)
   added: (1)
      0:{"id":"ya3a2SneG8k8o19Rrk2wl","intercept.v1":{"addresses":["log.ziti"],"portRanges":[{"low":80,"high":80}],"protocols":["tcp"]},"postureQuerySets":[{"policyId":"6SWG7DWs4QU9bJMqICz1H6","policyType":"Dial","isPassing":true}],"encrypted":true,"host.v1":{"address":"127.0.0.1","protocol":"tcp","port":6000},"permFlags":1,"name":"log.svc"}

[2022-09-29T14:18:30:802Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:207 updateTunnelNetworkSettings() route: 100.64.0.1 / 255.192.0.0
[2022-09-29T14:18:30:802Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:371 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     11: name:en0, type:wifi 
     20: name:utun5, type:other
[2022-09-29T14:18:30:803Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:210 updateTunnelNetworkSettings() excluding route: MYIP / 255.255.255.255
[2022-09-29T14:18:30:813Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:317 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 75.75.75.75
[2022-09-29T14:18:30:814Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:356 startNetworkMonitor() Setting fallback DNS to 75.75.75.75
[2022-09-29T14:18:30.814Z]    INFO tunnel-cbs:ziti_dns.c:205 ziti_dns_set_upstream() DNS upstream is set to 75.75.75.75:53
[2022-09-29T14:18:31:483Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:371 logNetworkPath() Network Path Update:
Status:satisfied, Expensive:false, Cellular:false, DNS:true
   Interfaces: 
     11: name:en0, type:wifi 
     20: name:utun5, type:other 
     30: name:utun6, type:other
[2022-09-29T14:18:31:496Z]    WARN PacketTunnelProvider:PacketTunnelProvider.swift:317 getUpstreamDns() No fallback DNS configured. Setting to first resolver: 75.75.75.75
[2022-09-29T14:18:31:496Z]    INFO PacketTunnelProvider:PacketTunnelProvider.swift:356 startNetworkMonitor() Setting fallback DNS to 75.75.75.75
[2022-09-29T14:18:31.496Z]    INFO tunnel-cbs:ziti_dns.c:205 ziti_dns_set_upstream() DNS upstream is set to 75.75.75.75:53
[2022-09-29T14:18:33.981Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-29T14:18:33.981Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 19107 ms (attempt = 2)
[2022-09-29T14:18:50.059Z]    INFO ziti-sdk:posture.c:190 ziti_send_posture_data() ztx[0] first run or potential controller restart detected
[2022-09-29T14:18:53.093Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-29T14:18:53.093Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 18988 ms (attempt = 3)
[2022-09-29T14:19:12.085Z]   ERROR ziti-sdk:channel.c:875 on_channel_connect_internal() ch[0] failed to connect [-3008/unknown node or service]
[2022-09-29T14:19:12.085Z]    INFO ziti-sdk:channel.c:740 reconnect_channel() ch[0] reconnecting in 70535 ms (attempt = 4)