Ziti basic architecture help

I am working on a basic security lab to test and implement various Ziti elements. Here is a simplified view for discussion purposes of this proposed network to be secured:

This network will simulate the average office / enterprise with an internal network of hosts and devices and servers connected via wired ethernet on one firewall interface, a reverse proxy for web application delivery to Internet users on its own DMZ interface, and a WiFi network on its own DMZ interface. The firewall currently does NAT for all 3 of these interfaces. The Internet interface is to an ISP and uses one publicly reachable IP address.

My questions are about the best way to approach a typical enterprise network like this with hosted web applications and remote administration being the primary inbound traffic at this stage of the lab experiment.

  1. What is the best way to utilize OpenZiti with this environment?
  2. How should OpenZiti elements be logically placed and configured? Tunnels, edge router, controller? I’d appreciate some help in understanding the intended approach to an environment like this one as I try to learn and understand Ziti enough to gain confidence in possible commercial implementations.

The “internal network” consists of various OS platforms and hardware devices, servers running as VM and Docker containers, etc.

  1. I understand that my reverse proxy DMZ and service is essentially unnecessary in a zitified environment- how close are we to having BrowZer ready as that’s how I’d like to represent a lot of these web services to users?
  2. Is there a way to direct all inbound traffic to a tunneler rather than allow connections to the actual network IP address? Is that a relevant question?
  3. This seems like a perfect example to try to use the Browzer component since the main service this network provides to the Internet is a list of about 15 web applications (currently running on various reverse proxied ports on the translated external IP address).
  4. Does the Ziti zero trust paradigm essentially remove the need for this hardware segmentation at the firewall? Does each server instance and host need to run some sort of client software?
  5. I think the actual first logical question here, since I need to start with an OpenZiti network, is about setting up a local controller. I’m happy to do that with Docker and have the instructions loaded up to do so, but are there design considerations about where that controller sits or what that controller does with other Docker containers? Should it be isolated? Can it run on low-powered hardware like a heavily utilized ARM processor NAS? Would love to hear best practices on controller network location and optimal hardware requirements.

Would really appreciate any and all help translating my old school knowledge and experience to the new Ziti paradigm. Thanks for the help and discussion.

2 Likes

Hi @jfj, welcome to the community. So awesome to see you looking into OpenZITI. You took a bit of time to ask your questions, so I'll return with the same. The heart of your endeavor seems to be this: "...with hosted web applications and remote administration being the primary inbound traffic..." Let's set aside the BrowZer part for now and come back to it later.

TLDR;

What you are trying to achieve is loosely outlined in this guide. The only differences are that the cloud graphic collapses into the bottom right private network (your home/office) as this is where you seem to want to host the Controller and Fabric Edge Router, and the top left network is replaced by roaming client/Tunnel identities roaming around on the Internet. So, A) remove installation of the top left network components and replace it with installation of a client/Tunnel app and B) place the cloud components in your DMZ (Controller and Fabric Edge Router). The LAN would have either a private Edge Router or Tunnel that has access to all of the web services in the LAN.
The key to all of this is that the Controller and Fabric Edge Router must be reachable by the Internet components, as well as the short hop over the wall by the private Edge Router/Tunnel in the LAN that your services exist in. In your case, they "meet in the middle" in your DMZ.

Gotta Have the Info!

Your lab environment is an easy one to solution in its current form. It is only one "service site" with the things that need to access those services floating around on the Internet. No sweat.

  1. What is the best way to utilize OpenZiti with this environment?

The BEST way to use OpenZITI is take the SDK for edge identity and integrate it into application runtimes at both ends. The result is the truest form of Zero Trust. However, I think what you are trying to achieve is accomplished using our precompiled tunnel apps, which have the SDK baked in. I'll explain more below.

  1. How should OpenZiti elements be logically placed and configured? Tunnels, edge router, controller? I’d appreciate some help in understanding the intended approach to an environment like this one as I try to learn and understand Ziti enough to gain confidence in possible commercial implementations.

A lot of variables go into an answer to this. Have you seen the components break down at What is OpenZiti? | OpenZiti ? Check that out for the basics on what the components are. For your setup, you'll need at least: 1x Controller, 2x Edge Routers (with 1x of them being inside your private network and 1x public/Internet reachable), and a handful of "Tunnels" in the form of the devices/OSes you'll be permitting access to. You will need to ask yourself one question to determine where the Controller and public Edge Router components live. The benefit of Ziti comes from the fact that it can abstract your attack surface from your private LAN to Internet edge away from the private network. If you choose to host the Controller and public Edge Router components in a cloud or datacenter like we do in our SaaS (NetFoundry Console), then your firewall no longer needs to listen and forward. You can host the components in your own DMZ too though, but you need to make this determination. See the document on this topic.

  1. I understand that my reverse proxy DMZ and service is essentially unnecessary in a zitified environment- how close are we to having BrowZer ready as that’s how I’d like to represent a lot of these web services to users?

Let me start by saying that BrowZer represents an amazing way to achieve Zero Trust. Pow, right in the BrowZer! It leans on the ability to validate against an IDP for authenticated users to present themselves to a detached gateway on the Internet. At the point of validation, that gateway explicitly connects the user's browser to the private resource through Ziti in a way that looks exactly like a Tunnel would. The benefit is no added software to install. It is REALLY hard to achieve this level of hands off, and we are working to make it seamless. Documentation is not ready yet, but you can implement it if you are adventurous (and forgiving of a few bugs here and there). I or a colleague will follow up after this post with links to other posts that get into how you'd do it. I would recommend you come back to this if you need to get up and running quickly though.

  1. Is there a way to direct all inbound traffic to a tunneler rather than allow connections to the actual network IP address? Is that a relevant question?

Full-Tunnel Capture? Sure! This is a more loaded question than you'd imagine though. Ziti was designed around the concept of applications. So, while you can instruct a Tunneler to capture all egress traffic (and even send it selectively to different edges!), there are a few trimmings to Full-Tunnel that it doesn't perform. For instance, implicit DNS redirection as well as assignment of a local IP at the termination network (Tunnel = Proxy). Your service would be setup as to intercept two ranges (0.0.0.0/1) and (128.0.0.0/1) and egress them by forwarding to the termination edge wherever that is. You'd need a service to intercept DNS if you wanted requests to go to your internal resolver. Then there is the dreaded walled garden that presents itself at some hotels and businesses, which means your clients would need to understand to turn off Ziti to go through that first before it is allowed through the garden. This question alone probably warrants its own post, so when/if you wanted to go down that path we can start a thread (or redirect to an active one that I'm sure has been started).

  1. This seems like a perfect example to try to use the Browzer component since the main service this network provides to the Internet is a list of about 15 web applications (currently running on various reverse proxied ports on the translated external IP address).

This could be, though the client/Tunnel model would work as well. The only difference, aside from the Tunnel model being well matured at this point, is the ability to identify the devices needing access and having the Tunnel with permanent identity installed to them. I recommend to start with the client/Tunnel model and add in BrowZer once you have gotten things working as you require.

  1. Does the Ziti zero trust paradigm essentially remove the need for this hardware segmentation at the firewall? Does each server instance and host need to run some sort of client software?

Recall back to the components. One of the Edge Routers would be internal to your network. It is that Edge Router that is terminating towards the services in the network it can reach in the LAN on behalf of the clients/Tunnels that you give access to. This component is run as a VM (ideal) or container, or direct on Linux. There are other clever ways to terminate traffic into the LAN for the same function, but the ideal is to have a dedicated "thing" to do so.

  1. I think the actual first logical question here, since I need to start with an OpenZiti network, is about setting up a local controller. I’m happy to do that with Docker and have the instructions loaded up to do so, but are there design considerations about where that controller sits or what that controller does with other Docker containers? Should it be isolated? Can it run on low-powered hardware like a heavily utilized ARM processor NAS? Would love to hear best practices on controller network location and optimal hardware requirements.

You mention "local controller" such that it makes me think you do want to run this in the same network as services provided. That's totally OK to do as long as you understand it won't remove the need for a DMZ if you do so. The Controller is important to the network, and ALL components must be able to reach it from wherever they are. You will want to review the HOST ANYWHERE instructions. The QuickStart for Local with Docker is exactly that - for local and demo use. Some of your components (Edge Router and clients/Tunnels) will live outside of the LAN, so you need to host them in such a way that those components can reach the Controller. I don't know how sophisticated your firewall is for routing and segmenting, but keep in mind those requirements to host in the document. The Controller is a device that is designed to handle a lot. Provision it with that in mind. I wouldn't run it on anything else but fully or semi dedicated hardware (IE don't put it on an overloaded VM host). It is written in GO, so I'd imagine you can put it in places that are unusual, but my recommendation is to put it on something that can scale up when/if the time comes.

2 Likes

@NicFragale , thank you so much for taking so much time to answer in detail and to do it so quickly. I promise you that your help will be gratefully used and appreciated- you’ve filled in a lot of the blanks for me here that I just wasn’t getting reading documentation and other forum posts. I’m going to get started with this (the comments about running the controller in my DMZ are especially good as a starting point, and I’ll have to see about hardware on that first) and I’m sure I’ll have some clarifying questions but for now I’ll make sure I’ve done my reading and run into some specific issues before I ask too many more questions. Hopefully other folks with backgrounds in network security will find your comments helpful.

I do understand that the ideal is that you go the SDK route with your apps, and I have a client for whom that’s a very real option. Before I can recommend that, however, I’m trying to learn enough in the lab that I can give some good advice, so for the web apps involved here we’re talking about simple stuff that runs on VM’s and containers using publicly available images, etc. The BrowZer discussion is the most important for a specific client of mine in the end, but as you correctly say I should get my head around the overlay components and ins and outs first. I’m sure I’ll have some questions about DNS and certificates next.

Thanks again for such a thoughtful reply. I’m really excited to embrace the ZiTi approach, the old models are a waste of time and money in the modern world. The adjustment is just going to take me some time and that’s what this lab is all about. This kind of help is crucial.

Cheers,

-John

1 Like

@jfj Really happy to hear you are diving in as you are. All of NetFoundry watches Discourse for questions. Sometimes we fight over who answers what :slight_smile: . A lot of us use the project (from Sales to the Exec-Team) for our own lives. I personally use the project to enable my family to tap into multiple geo-dispersed camera systems/NVRs and home automation systems that would be a nightmare to translate into the “old world” of VPN/SDN overlays. If you ever started a topic on Home Assistant, I’d likely be the first to reply. (I’m running HAOS on a raspberry pi with an integration for Ziti that I wrote/compiled - to be released to the marketplace soon but if you search GitHub for netfoundry-ha you might see me).

Alongside BrowZer, we have another utilization of the core project with ZROK. Totally check that out if time permits.

We can continue on this thread as you go along. All of us are thankful for those who carry the light to others. Keep at it!

1 Like

By the way - A colleague mentions he has worked on automation for OpenZiti BrowZer, which potentially could make its way into mainstream. Here is a Docker whale teaser for you :stuck_out_tongue:

image

1 Like

I’m trying to not get too in depth on what exactly I’m hosting in this lab because the end goal is really to see it used for my clients and I hope that my own “fun” stuff is representative enough to provide some lab test cases that are referenceable for that purpose, but to be specific I run the usual “homelab” sorts of things here despite it being a professional office and not a home network. Media streaming of multiple sorts, various tools (speed tests, prometheus / grafana, vaultwarden, snort, suricata), NextCloud, etc. These are all either Docker containers on multiple servers or VM’s running on ProxMox. I even have a few ProxMox LxC’s. I will also be doing an NVR port but that’s for later. No actual automation, but one of the drivers for my interest in BrowZer even in this lab environment is that I’ll be accessing many of these services with IoT devices like a roku streaming stick, so a client won’t work.