Since the windows-desktop-edge currently does not remember if an identity is disabled after a reboot (see: Support remembering disabled identities on reboot/startup · Issue #681 · openziti/desktop-edge-win), is there any way to disable a service based on the IP/Location or local reachability of the designated host?
Or alternativly can you add an exception to the interception? (like intercept *.domain.local but not storage.domain.local)
To give an example:
I have a service which provides me with access to our office server network (say: 192.168.0.0/24 and *.domain.local).
In this network there is a NAS (reachable via storage.domain.local).
I need this resource to be available via ziti when I am out of office.
But when I'm inside of the office, the traffic would be unnecessarily routed via ziti, even if I have direct access.
I already seperated the services in two different identities, so I can disable the office-access on demand, but since ziti does not remember the disabled identity I have to remember it myself (which I forget quite often). This means I'm sending around 40GB of traffic through ziti every day
Is there any way to have like a posture-check or something, that disables a service or IP if it is directly reachable? Or maybe have a posture-check which is based on the IP-Address the client has?
I could also live with excempting the address (storage.domain.local) from the intercept, but I guess this would mean to have all resources listed seperatly (dc1.domain.local, web.domain.local instead of *.domain.local, etc).
You guys know of any charming way around my problem?
I have been using 2.5.1 for a month ish now, so I could probably promote it to stable. I'll ask around to ensure others at least internally have been using it and if so, I'll just promote it...
Numerous people have been on 2.5.1 for a month, so we've promoted it to stable just now. Would you please update to stable and see if it resolves the remembering of the state for you?
I assume that will resolve your issue, but if not and you'd like I can offer other thoughts on the rest of your post?
Thanks, been on stable this whole time! Just updated to 2.5.1 and remembering solves my main problem.
I would still be interested in your opinion on the topic.
I did not find a solution to determine if the client actually is in the desired network or has it directly attached.
I guess it would be possible to make an edge router in the office, have the client connect to it with a lower route cost, so the traffic does not flow through the default edge router thus leaving the ISP connection out of it. But I guess this would have an impact on all the clients if the router is only reachable internally (trying to connect but never reaching the target).
Is it possible to make a transit route only available from specific source addresses? Or make the routing based on the location of the client? This way my client could connect to the public edge if it is outside of the network, and connect to my private edge if it is inside the network, thus reducing the stress on the ISP.
Or maybe offer two public routers but set a preferred one which is only tried once?
Only other solution I could think of is entire exempt the desired network from the identity, so it never gets routed and use a seperate identity which only connects the desired network.
Geolocated enable/disabling is certainly a feature that has been requested in the past. We haven't implemented it yet, but I'm confident it'll get enabled some day -- I don't know when.
Using a local router would be what I'd recommend yes. "the traffic would be unnecessarily routed via ziti" <-- Oh no we're trusting the local network here! I realize that it's easier for sure and almost certainly 'safe enough" but working on a zero trust project that I believe in, I feel compelled to point out that ziti is useful even for internal, private networks. After all "land and expand" is a very real risk... (end public service announcement that zero trust everywhere is the future hehehe)
With the router local, you'd set the public router cost foolishly huge so that the local traffic doesn't eventually leak out to the public router. Since the costing is dynamic, at some point you're likely to leak out/back again to the public router which isn't what you'd want. I don't know what values are appropriate tbh, this isn't a deployment model I've used myself yet but that's the idea.
As for performance issues, I don't think that would be an issue at all. There are plenty of deployments that use "private edge rotuers" in this way. Ziti is built to handle it and if you find a situation that doesn't work, we'll fix that qiuckly because it's important that it not be a problem. (it hasn't been to date)
Another thing you could choose is to enable a TOTP posture check on your identity -- assuming you sleep it, hibernate it, turn it off when you travel. Then you can choose to do things like set the identity to "lock" on wake or just set the TOTP timeout to something sufficiently small. That way, when you come back to the machine, the identity (or better perhaps, just that ONE service) would be disabled and you'd be unlikely to notice it being disabled until you left the office.
I do think there's some kind of improvement here for OpenZiti to implement, I just don't know when it'll get the prioritization to be implemented.
Definitively helps, I'll test it out.
I'm all up for sending all traffic to resources via the zero trust network, since no network (even the local one) should be trusted. My concert is just the traffic flow, which can be optimized with the local router.
Would'nt all external clients still try to lookup edge.domain.local and try to reach this router over and over again? Or does the tunneler know, that die domain is not resolvable and stop after a few retries?
Or if the domain would be resolvable but the ip and port not reachable from the outside, would the client still try to connect it over and over again?
I guess the "best" way would be to have a setting on the edge routers which source addresses are allowed to connect. So we could place multiple edge routers and say the "public" one is reachable by 0.0.0.0/0 but the private edge router only bei 10.0.0.0/8 or something like that.
