I have some questions regarding NAT traversal - most importantly: Does OpenZiti support that?
Two potential scenarios come to my mind:
Two clients in different private networks want to communicate with each other and don't have a public IP address. The controller is hosted on a host with a public IP, though.
A browser from another network (e.g., a private network or even a mobile network) wants to access an HTTP service run in one of the private networks without a public IP. Is NAT traversal also supported by BrowZer?
Does the controller take care of UDP hole punching? In the end, I would like to bake some of the functionality provided by services like Nebula or Tailscale right into the application without depending on 3rd party providers.
I tried to answer these questions myself by just trying out the OpenZiti examples. Unfortunately, most of them are a bit outdated and don't work out of the box anymore (especially the docker-compose one).
Zrok seems like it supports NAT traversal, however, I'm not sure if that is something built on top of OpenZiti.
Hi @lemoony, welcome to the community and to OpenZiti!
I'll do my best to answer your questions in the order that makes sense to me. Hopefully the order will make senes to you too.
OpenZiti eliminates NAT traversal problemss due to the overall design of OpenZiti's. All traffic rendezvous through a software router (refered to as "edge routers"). Since the traffic all goes through a router in this way, when deploying your overlay network there's an edge router reachable from both "sides" of the overlay network. This means the 'client/initiating' side connects to a router (or many) and so does the 'server/terminating/offload' side by making outbound connections. This totally takes NAT out of the equation.
BrowZer is no affected by NAT traversal issues. BrowZer-based solutions will connect from the web browser to a websocket-enabled edge router to initiate the zero trust connection. Once connected to the edge router, BrowZer will send all bytes through the OpenZiti overlay to the offload location. It (basically, there's nuance here) works like any other SDK-based endpoint.
At this time, OpenZiti is entirely TCP and UDP hole punching is not a problem. In the future when we move to a UDP-based approach, this answer might be yes, it might be no. Since we use TCP, it's not a question that can be answered precisely at this time.
Probably need a case-by-case for this to see if there are features that are equivalent/different that OpenZiti provides but at the end of the day, OpenZiti is just a very secure bit pipe. You can run any other application (along with any other encryption) you want over OpenZiti fine (such as ssh, https, etc, etc).
Oh no? That seems like we need to fix something. If you can give specifics, that'd be really helpful. I'll see if I can replicate what you're seeing. Thanks so much for reporting that!
zrok is a ziti-native application and relies on the OpenZiti overlay. It functions similar to the OpenZiti tunnelers but since it's a whole thing of its own it can do some things for users to make it easier. Under the hood of zrok is a full OpenZiti network though. (this makes me think it would be a good blog post: Introducing zrok).
Hi @TheLumberjack , thanks for the very quick response! I understand your points and I think most of my most pressing questions have been answered. I really have to dig deeper into the documentation
Some points regarding the examples:
With docker compose, the ziti-private-red and -blue failed to start
With docker, the command to start the admin console references unknown volumes
The curl examples don't work via HTTP as stated by the documentation, https:// has to be used
You probably were unlucky on this one and got a bad image that had a bug in it. If you are so inclined to try again, can you docker compose pull? I just tried again with the latest image tag (sha: b48b9861839c) and it came up. I do think there was a bring-up bug somewhere along the way, though.
