I am finding it quite helpful in testing to associate identities with their associated IP address. I am not sure if an IP address exists until a service is bound to the identity. But if an IP address is assigned it would be helpful to see it here in another column.
If there is another place where this can be seen I would love to know where it is. Also, if IP addresses are not a primitive that matters (totally ephemeral and not a 1:1 relationship), that would be helpful to know (I haven’t come across that in the docs if so).
@jptechnical Help me get a lock on what you’re looking for. It’d be a column like “Last Known Address” that would be detected and reported by the Ziti software? You’d want the primary interface address or the internet egress NAT address? What should it be for a container, the same primary interface address, e.g., Docker bridge IP?
Meanwhile, I’ll check on what details are uploaded by Ziti periodically. Those details are where the OS column comes from. There’s a bit more, but not sure yet about network info.
Also, would you expect something different if the identity is not a tunneler?
Here’s a snippet of an enrolled identity’s environment info from the management API:
"envInfo": {
"arch": "amd64",
"os": "linux",
"osRelease": "6.4.6-76060406-generic",
"osVersion": "#202307241739~1690928105~22.04~d567a38 SMP PREEMPT_DYNAMIC Tue A"
},
1 Like
Are you referring to the dynamically generated IP addresses that are assigned to hostnames in wildcard domains? If so, those IPs are specific to the hostname that was looked up at the intercepting tunneler. So if you looked up foo.mydomain.ziti on two different hosts, you’d very likely get a different IP on each host.
Continuing my possibly bad assumption that your interest is in the IPs for wildcard hosts, here are a few ideas:
-
Based on our discussion in another thread I’m guessing the reason you care about the IPs is because you’re having a hard time getting ziti DNS and your upstream DNS working at the same time. So I’m guessing that if DNS was fully working then you wouldn’t need to be so concerned about the IPs. One way to do this would be to tell ziti-edge-tunnel where to forward requests for hostnames that it doesn’t know about with the --dns-upstream command-line option
-
The wildcard DNS address in a service’s intercept configuration has an analogue for IP addresses. Instead of naming your identities to match the fqdns in your wildcard domain, you could intercept a CIDR range like “12.34.56.0/24” and name the identities to match IPs that are in the CIDR (e.g. “12.34.56.78”). For this to work you’d need to use $dst_ip instead of $dst_hostname for the dial identity in the intercept configuration.
Whether or not the above options are appealing to you, we certainly could add the internal DNS server’s hostname:ip mappings. I’d think the output from ziti-edge-tunnel dump would be an appropriate place.
1 Like
The endpoint's apparent IP address (That seen by the controller) is available in the API sessions since it is dynamic.
You can retrieve these via the CLI with
ziti edge list api-sessions -j | jq '.data | .identity["name"], .ipAddress'
This will only show the active api sessions, but for anything that is bound, an api session is a prerequisite.
You could also do this via the API, of course, depending on what you need.
1 Like
This is all great feedback… it helps me get my head around it.
Yes, my assumption was that dig servicename.mydomain.ziti would go to the same IP address regardless of the host I dig it from. So the concept that IP addresses are not statically assigned to an identity makes sense. But it will require a little bit of head-scratching for my present use cases.
Here is some context. Every ZTNA (claiming) application I have used will assign a static IP to a device when added. That IP is fixed for the life of the device. The resources on that device can be accessed via that predictable and known IP address, and DNS can be worked around accordingly. In the case of Todyl, they only support windows active directory 
, in the case of Privatise they provide their own bundled piHole. In either case, for consistency and bullet-proofing I would add a windows hosts file record for any critical service.
So, these things considered, I don’t see that adding an IP address to the dashboard of identities makes any sense. So I withdraw the feature request with thanks for the clarification.
OK, so I think Scareythink may have been closer to your request than I was. The IP addresses used within OpenZiti are only in a local scope, to the node or the logical entity. That is, the DNS resolution for the various services only exist in that particular system, and links, etc use the TCP connection to create them, but OpenZiti routing only sees a link. Locally accessible services are addressed sequentially as services are loaded, so it is likely that two devices covered by the same policies would look the same, but that is coincidence, not design. IP addresses mean little to Ziti itself, and nothing to it’s routing (within the fabric). The actual presentation of services are done with the various logical entities of OpenZiti, initiators, terminators, links, etc. It is a complete abstraction. Of course IP addresses are tracked and used to get traffic into and out of the overlay network, but once inside, they don’t mean anything. I find it more difficult to wrap one’s head around that the more you know about networking, your experience fights you every step of the way. I have the benefit of doing most of my networking in carrier wireless, which has a lot of tunneled connections through the infrastructure, so I was halfway there to start.
1 Like
This is true for plain hostname intercept addresses. For wildcard domains, the IPs are assigned to hostnames as they are requested. So given an intercept address of "*.ziti" and the following sequence of queries that reach the ziti DNS server, we'd have IPs like this:
| hostname |
IP |
| fee.ziti |
100.64.0.3 |
| fye.ziti |
100.64.0.4 |
| foe.ziti |
100.64.0.5 |
etc..
Also note that this sequence would be altered by queries for hostnames in other wildcard domains, since the DNS IP range applies to all ziti hostnames (wildcard or plain). For that matter, the sequence would be altered by a service update that adds a plain hostname intercept address.
What determines this IP? is it in a subnet that could be specified as an intercept address for the ziti service?
They are all in a private subnet, the same subnet for each tenant, in fact. IPs are assigned as devices are enrolled. I don't believe there is an option to change them. If you delete a device, that IP is assigned to the next device that enrolls, in my experience.
To clarify, I wasn't implying that what I have seen is the 'right way', just the observation of how I have seen it done. Ziti is unique in my testing for how it addresses devices. It's part of it's charm and allure, it's exotic 
This is an excellent point, and hints at what I think is one of openziti's main differentiators the overlay space. The tunnelers that most people use when starting out with openziti are really just applications that use the openziti SDKs to proxy tcp/ip & udp payloads across an overlay. Concepts like IP addresses and ports are only meaningful to the tunnelers. The controller, routers, and SDKs know nothing of layer 4, and I think this explains why openziti stands out in terms of addressing. But the tunnelers are not the only way to use openziti.
You can write your own app that uses the openziti SDKs to communicate on the overlay. When you do this, the mTLS connections terminate in the memory of the apps on either side of the connection.
