Thanks a lot for the comprehensive answer.
Do you already have articles depicting the „intercepting all traffic“ approach?
@dmuensterer, @gnz has provided very good detailed information related to your questions. In fact, we are currently working on updating the openziti docs to add relevant information for new users like yourselves and walk you through the deployment architectures that are possible with openziti. I wanted to understand from you if you don’t mind providing some valuable feedback to us on our changes thus far. Here is a preview draft of what that may look like. Overview | OpenZiti Please let us know if that would have answered some of the initial questions(s) you had. If not what would have helped and needs to be added. Thank you!!
2 Likes
@dmuensterer wrt to you question to a specific deployment scenario, where you want to intercept all traffic at your remote client, or at least sessions to private applications hosted in the private datacenter, there are a couple of deployment architectures depicted there that fits your use case and depends what you mean by all.
-
Client to router
-
Client to host
- All means internet and private destinations -
client to router, internet destination would forwarded to the internet destination through some type of Secure Internet Gateway located in the data center, private destination would be forwarded to servers located inside the data center,
Advanced service that includes all Public and 1918 IP space. Service configuration for intercept.v1 would look something like this:
{
"protocols":["tcp"],
"addresses":["64.0.0.0/3","168.0.0.0/6","176.0.0.0/4","208.0.0.0/4","0.0.0.0/5","24.0.0.0/5","32.0.0.0/5","56.0.0.0/5","96.0.0.0/5","112.0.0.0/5","136.0.0.0/5","152.0.0.0/5","160.0.0.0/5","16.0.0.0/6","44.0.0.0/6","48.0.0.0/6","108.0.0.0/6","120.0.0.0/6","144.0.0.0/6","200.0.0.0/6","8.0.0.0/7","14.0.0.0/7","20.0.0.0/7","42.0.0.0/7","54.0.0.0/7","106.0.0.0/7","124.0.0.0/7","128.0.0.0/7","134.0.0.0/7","148.0.0.0/7","174.0.0.0/7","194.0.0.0/7","196.0.0.0/7","206.0.0.0/7","11.0.0.0/8","12.0.0.0/8","22.0.0.0/8","41.0.0.0/8","53.0.0.0/8","105.0.0.0/8","126.0.0.0/8","130.0.0.0/8","133.0.0.0/8","151.0.0.0/8","173.0.0.0/8","193.0.0.0/8","199.0.0.0/8","205.0.0.0/8","13.128.0.0/9","23.128.0.0/9","40.128.0.0/9","52.128.0.0/9","104.0.0.0/9","131.0.0.0/9","132.0.0.0/9","150.0.0.0/9","172.128.0.0/9","192.0.0.0/9","198.128.0.0/9","204.128.0.0/9","13.0.0.0/10","23.0.0.0/10","40.0.0.0/10","52.0.0.0/10","104.192.0.0/10","131.128.0.0/10","132.128.0.0/10","150.192.0.0/10","172.64.0.0/10","192.192.0.0/10","198.64.0.0/10","204.0.0.0/10","13.64.0.0/11","23.64.0.0/11","40.64.0.0/11","52.64.0.0/11","104.160.0.0/11","131.192.0.0/11","132.192.0.0/11","150.128.0.0/11","172.32.0.0/11","192.128.0.0/11","198.32.0.0/11","204.96.0.0/11","13.112.0.0/12","23.112.0.0/12","40.112.0.0/12","104.128.0.0/12","131.224.0.0/12","132.224.0.0/12","150.176.0.0/12","172.0.0.0/12","192.176.0.0/12","198.0.0.0/12","204.80.0.0/12","13.96.0.0/13","23.104.0.0/13","104.152.0.0/13","131.240.0.0/13","132.248.0.0/13","150.160.0.0/13","192.160.0.0/13","198.24.0.0/13","204.64.0.0/13","13.108.0.0/14","23.96.0.0/14","52.100.0.0/14","52.108.0.0/14","52.116.0.0/14","52.124.0.0/14","104.148.0.0/14","131.248.0.0/14","132.240.0.0/14","150.172.0.0/14","192.172.0.0/14","198.20.0.0/14","204.72.0.0/14","13.104.0.0/15","23.100.0.0/15","40.106.0.0/15","40.110.0.0/15","104.144.0.0/15","131.254.0.0/15","132.246.0.0/15","150.168.0.0/15","192.170.0.0/15","198.16.0.0/15","204.76.0.0/15","13.106.0.0/16","23.102.0.0/16","40.109.0.0/16","104.147.0.0/16","131.252.0.0/16","132.244.0.0/16","150.170.0.0/16","192.169.0.0/16","204.78.0.0/16","23.103.0.0/17","40.108.0.0/17","104.146.0.0/17","131.253.128.0/17","150.171.128.0/17","204.79.0.0/17","13.107.192.0/18","23.103.192.0/18","131.253.64.0/18","150.171.64.0/18","204.79.128.0/18","13.107.32.0/19","13.107.160.0/19","23.103.128.0/19","131.253.0.0/19","150.171.0.0/19","204.79.224.0/19","13.107.144.0/20","23.103.176.0/20","131.253.48.0/20","150.171.48.0/20","204.79.208.0/20","13.107.8.0/21","13.107.24.0/21","131.253.40.0/21","204.79.200.0/21","13.107.0.0/22","13.107.20.0/22","13.107.132.0/22","13.107.140.0/22","131.253.36.0/22","150.171.36.0/22","150.171.44.0/22","204.79.192.0/22","13.107.4.0/23","13.107.16.0/23","131.253.34.0/23","204.79.198.0/23","13.107.7.0/24","13.107.19.0/24","131.253.32.0/24","204.79.196.0/24"],
"portRanges":[{"low":443, "high":443},{"low":80, "high":80}]
}
- If all means only all private services -
Client to routeras well , but obviously the service configure would have less ip prefixes, i.e only entire 1918 ip space or perhaps some narrow range of specific ip subnets. The internet traffic would break out locally at the client.
{
"protocols":["tcp"],
"addresses":["10.0.0.0/8","172.16.0.0/12 ","192.168.0.0/16"],
"portRanges":[{"low":443, "high":443},{"low":80, "high":80}]
}
- You could use
router to host deploymentfor the all private services case as well but then you would need to configure a service per destination, since each service would terminate on each host, more secure but at lot more of services.
Also, the service configuration can contain urls or wildcard urls as well instead of ips, or mix of both.
2 Likes
That really helps!
Thanks a lot for the continuously helpful responses.
I will implement OpenZiti in my infrastructure and get back to you with feedback.
Best regards
3 Likes
We are glad that it helped and even more excited that you are deploying openiziti. We are all here to help everyone succeed deploying openziti and securing access to apps/workloads everywhere at the same time. And please provide feedback if you have any, especially around documentation.
@TheLumberjack I’m having another issue setting up a service and connecting the identity on my mac.
I’ve enrolled the JWT and am connected to the controller but no service is displayed.
The service name is “client_access”
On the controller side, when editing the identity I can test the service:
CLIENT_ACCESS.SVC CONNECTION ISSUES
(Bind)
Everything is configured properly
Any ideas? Which setting determines if the service is shown on the tunneler side?
I can’t find any adjusted DNS records for Ziti, no record similar to 100.64.xx.xx
Appex.log
[2022-10-19T11:13:10:085Z] INFO PacketTunnelProvider:ZitiTunnelDelegate.swift:219 tunnelEventCallback() ZitiTunnelEvent: <CZiti.ZitiTunnelServiceEvent: 0x140915f10>
identity: dm_mb:"IyxzNPdkY"
status:
removed: (0)
added: (1)
0:{"id":"4r0xsQBOdM30WRFHs2DH2k","intercept.v1":{"protocols":["tcp"],"portRanges":[{"low":443,"high":443}],"addresses":["01.ziti"],"dialOptions":{"identity":"","connectTimeoutSeconds":5},"sourceIp":""},"postureQuerySets":[{"policyId":"77QSBDgFNr2dayMa95yvkv","policyType":"Bind","isPassing":true}],"encrypted":true,"host.v1":{"address":"127.0.0.1","protocol":"tcp","port":9000},"permFlags":2,"name":"client_access.svc"}
[2022-10-19T11:13:10:095Z] INFO PacketTunnelProvider:PacketTunnelProvider.swift:207 updateTunnelNetworkSettings() route: 100.64.0.1 / 255.192.0.0
[2022-10-19T11:13:10:095Z] INFO PacketTunnelProvider:PacketTunnelProvider.swift:210 updateTunnelNetworkSettings() excluding route: xxx.xxx.xxx.xxx / 255.255.255.255
Hi @dmuensterer - The macOS ZDE currently doesn’t display Bind services. I’ll put in an Issue for that. If you select “Snapshot…” from the menu bar you should see the service listed.
Thanks. Hmm, but I’m pretty sure I’ve already seen a service listed there whilst playing around with the hello world http example.
Right now, the problem is not only that it isn’t listed but also doesn’t work.
So my configured route 01.ziti doesn’t exist as well…
How are you testing the service? Do you have two endpoints or just this one? Being able to see how the two (assuming desktop edge/tunneler on both sides) configs are setup (intercept.v1/host.v1) is important sometimes.
Can you run the policy advisor for the two identities in question? ziti edge policy-advisor identities shows all the policy information for all your identities (dunno how many you have).
If the service is Bind-only I wouldn’t expect to see it displayed - there is currently a check when adding to the list of services to display to only add the service if the identity canDial() it. It’s possible there is a problem with the logic there. I added issue Bind services are not currently displayed in the ZDE Manage Tunnels view · Issue #117 · openziti/ziti-tunnel-apple · GitHub and run through some scenarios to see if I can find other issues. Can you post the Snapshot results here?
Sure, that’s the result of the snapshot:
=================
Ziti Context:
ID: 0
Enabled: true
Config: (null)
Controller: https://mycontroller.com:8441
Config types:
ziti-tunneler-client.v1
intercept.v1
ziti-tunneler-server.v1
host.v1
Identity: dm_mb[IyxzNPdkY]
=================
API Session:
Session Info:
api_session[cl9fjct366jqql47ob557a9nb]
api_session_state[3]
=================
Services:
client_access.svc: id[4r0xsQBOdM30WRFHs2DH2k] perm(dial=false,bind=true)
config[intercept.v1]={"addresses":["01.ziti"],"dialOptions":{"connectTimeoutSeconds":5,"identity":""},"portRanges":[{"high":443,"low":443}],"protocols":["tcp"],"sourceIp":""}
config[host.v1]={"address":"127.0.0.1","port":9000,"protocol":"tcp"}
posture queries[1]: posture query set[77QSBDgFNr2dayMa95yvkv]
==================
Sessions:
==================
Channels:
ch[0](zt-edge-router@tls://mycontroller.com:8442) connected [latency=17]
==================
Connections:
conn[0]: state[Bound] service[client_access.svc] using ch[0] zt-edge-router@tls://mycontroller.com:8442
==================
A ping 01.ziti gives me “Unknown host”.
I suppose, the problem might not even actually be on the Ziti network side but with the local DNS resolution?
Ok, so you are using the same machine for both intercept and host.
The mac client/safari/curl is accessing: https://01.ziti:443 which should tunnel up/down to the same mac where the client is binding the service and sending traffic to tcp:localhost:9000.
Stupid question but that should mean a curl -k https://localhost:9000 should work, right? I assume it does? 
I aslo see a posture query listed? Did you add a posture check too ?
Okay, let me just quickly recap what my intensions are - I wouldn’t rule out I just made a mistake in configurations:
I have a remote server with a https application running on Port 9000. There’s a linux tunneler running on the same host.
I have a client (MacBook) from which I want to access the application on 01.ziti:443
If opening port 9000 on the remote server I can access the application from the client.
yeah, it sounds like this is the problem then. what's the "remote host" (linux machine). that's the hostname you want on that address field. Right now your mac is trying to connect to "127.0.0.1:9000"
wooops - no i misunderstood the situation. Let me look at the info you provided again and see if there’s something I can recommend…
Ok. I think I get it now. I think you have the policy confused. Looking at the dump you provided i see:
perm(dial=false,bind=true)
for client_access.svc. That means your MAC is ‘binding’ the service . You want the mac to dial the service…
I think - double check the ‘dial’ policy for your mac
1 Like
Thanks! Yeah, so the tunneler is running on the same machine as my application, so I assumed 127.0.0.1:9000 should be correct to make the application on the server locally available?
I had “Must have all roles” activated by accident for both policies by accident - didn’t make any changes though after setting to “Has Any Role”.
Yah it definitely is the way to do it and definitely works. I think I figured out why the mac won't dial though with the previous comment. I think your mac identity needs the dial policy.
1 Like
I think you’re all set now, right? If not just let us know? I’m not 100% sure if you’re up and working or not, but I think you are…
1 Like