Ziti Configurations (forward versus non forward)

Support General Questions
1

Hi all,

I'm currently developing an API to automate configuration creation and would appreciate some clarification on the following:

  1. In ZAC, I noticed there are two options for service configurations: Forwarding and Non-Forwarding.
  • Non-Forwarding allows setting a single protocol, a single IP address (e.g., /32 or /24), and a single port.
  • Forwarding supports specifying a protocol, multiple addresses/ranges, and a port or port range.

Given that forwarding seems more flexible, what’s the rationale behind having both options? Are there specific features or use cases only supported by non-forwarding that I should consider? I want to ensure my API implementation doesn't overlook critical functionality by excluding non-forwarding configs.

Thanks!

2

Hi @Crystech, technically, you can opt to forward any of the tuple: protocol, address, port.

As to "why" it's useful, sometimes you want to authorize say: "ssh access, http to port 80, and DNS". To do this you have basically two options:

  • make three services and directly tie them:
    • TCP ssh.intercept:22 --> target.machine:22
    • TCP http.intercept:80 --> target.machine:80
    • UDP dns.intercept:53 --> target.machine:53
  • make one service and just forward the protocol and port but leave the address static:
    • TCP (forward), PORT (forward), address: target.machine

Like you said, it's a lot easier on the human to make the one service in this way, so it's entirely just a "human thing" for easier maintenance. Both options are equal. Arguably, the first one is slightly easier in the long run, in case you move a service, you just need to update the one service. With the second approach, you'll have to define a second service (but you had to do that with the first approach anyway).

I think it really just comes down to the humans looking at it. If it's all driven by API, I don't think it matters tremendously. There's nothing that comes to my mind why one is better than another.

Maybe the only down side to forwarding is those pesky humans again. If the human opens all ports 0-65535 well then any new service that shows up gets authorized. Maybe that's what you want? Maybe not? :slight_smile:

I don't know of any substantial reasons why forwarding is inherently good or bad - it's just up to your usage and you to decide.

1 Like
3

thanks for your inputs!

I am going to implement just using Forward method since technically we can have better flexibility especially on my frontend it will be api driven. I asked here just to make sure it wouldn't removed any functionality apart from "human behavior" things lol