# Ziti-tunnel proxy vs tproxy vs host configurations

**URL:** <https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573>\
**Category:** Uncategorized\
**Created:** [June 12, 2022, 5:55am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573 "2022-06-12T05:55:40Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![markamind](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/markamind/32/157_2.png) [@markamind](https://openziti.discourse.group/u/markamind)\
**Post date:** [June 12, 2022, 5:55am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/1 "2022-06-12T05:55:40Z")

</div>

I would like to validate my understanding of the differences between the ziti-tunnel proxy vs tproxy vs host configurations.

Questions that I have are

- what is different between the proxy and tproxy configurations
- what specific situations do you want to use a host

Please correct any of the following that is wrong.. this will be very helpful  
Thanks

# ziti-tunnel proxy mode

> used to access a zitified service accessible over the ziti network

**postgres db example:**  
ziti-tunnel proxy -i /mnt/v/temp/tunneler-id.json private-postgres:5432 -v

> taken from postgres demo  
> [ziti-sdk-jvm/samples/jdbc-postgres at main · openziti/ziti-sdk-jvm · GitHub](https://github.com/openziti/ziti-sdk-jvm/tree/main/samples/jdbc-postgres)

# ziti-tunnel tproxy mode

> used to access a zitified private DNS accessible over the ziti network

**guess on how to use**  
ziti-tunnel tproxy -i /mnt/v/temp/tunneler-id.json private-dns-name:5432

# ziti-tunnel host mode

> used to host a zitified service accessible over the ziti network

**guess on how to use:**  
ziti-tunnel host -i /mnt/v/temp/tunneler-id.json

> reference  
> [Update release notes. Add support for ziti-tunnel host. Add support f… by plorenz · Pull Request #262 · openziti/ziti · GitHub](https://github.com/openziti/ziti/pull/262/commits/3aef9d9bec485d833b48a526ab83b1a6eec47621)

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [June 12, 2022, 11:31am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/2 "2022-06-12T11:31:40Z")

</div>

Hi @markamind! Good question. Keep in mind that `tproxy` and `host` run modes of `ziti-tunnel` are deprecated by `ziti-ege-tunnel`, and so you should use ZET unless you have a particular reason for using the deprecated tunneler CLI. For example, if you need the `proxy` mode or if you’re modifying it in order to take advantage of Go language bindings to add some new capability.

Directly,

- `ziti-tunnel proxy` provides a raw TCP proxy for the named service that is listening on the specified loopback TCP port and does not provide a DNS nameserver. This is an “opaque” proxy because the application must be “aware” of the particular proxy address and port in order to connect. For example, the client application can not naively connect to the hosted service, but must instead connect to TCP://localhost:5432 in order to communicate with the server that is published as Ziti service “private-postgres”.

- `ziti-tunnel tproxy` is the “transparent” counterpart to `proxy`. This run mode provides a DNS nameserver and IPtables rules and IP routes in the OS so that client apps may connect to Ziti services transparently, naively, without being aware of the proxy at all. This mode is deprecated by `ziti-edge-tunnel run`.

- `ziti-tunnel host` merely hosts services without providing any proxy for intercepting IP traffic, and does not provide a nameserver. This mode is deprecated by `ziti-edge-tunnel run-host`.

---

<div class="post-metadata">

**Author:** ![markamind](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/markamind/32/157_2.png) [@markamind](https://openziti.discourse.group/u/markamind)\
**Post date:** [June 12, 2022, 11:57am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/3 "2022-06-12T11:57:31Z")

</div>

Thanks for that… its very helpful… and brings me up to speed.

Just to clarify… when I do a getLatest command… it does not bring down a copy of ziti-edge-tunnel… only ziti-tunnel

That being the case… what is the best way to get a local copy of ziti-edge-tunnel to distribute across the fabric.

Any tips?

---

<div class="post-metadata">

**Author:** ![TheLumberjack](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/thelumberjack/32/113_2.png) [@TheLumberjack](https://openziti.discourse.group/u/TheLumberjack)\
**Post date:** [June 12, 2022, 12:34pm UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/4 "2022-06-12T12:34:14Z")

</div>

Get latest is just a script that uses curl to grab the latest zip file/tgz and unpack the archive in a place. You can look at the source to see how it’s doing things.

You can just download the tunneler for your operating system at [Releases · openziti/ziti-tunnel-sdk-c · GitHub](https://github.com/openziti/ziti-tunnel-sdk-c/releases)

Usually this is for Linux OS, because there’s a store app from MacOS/iOS and an installer for Windows.

I’m thinking the old videos, before we moved to ziti-edge-tunnel should be redone.

You can check out another one I did recently too which uses ziti-router

[![](https://global.discourse-cdn.com/free1/uploads/netfoundry/original/1X/9572484ff71bb601622dbbe10a986d25b3c0c13e.jpeg "Totally Private Postgres") ](https://www.youtube.com/watch?v=ocUPWJbaG9o)

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [June 12, 2022, 1:40pm UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/5 "2022-06-12T13:40:35Z")

</div>

This is an example shortcut download link that always points to the latest release for the AMD64 / x86\_64 build for Linux.

[https://github.com/openziti/ziti-tunnel-sdk-c/releases/latest/download/ziti-edge-tunnel-Linux\_x86\_64.zip](https://github.com/openziti/ziti-tunnel-sdk-c/releases/latest/download/ziti-edge-tunnel-Linux_x86_64.zip)

---

<div class="post-metadata">

**Author:** ![Metz](https://avatars.discourse-cdn.com/v4/letter/m/c77e96/32.png) [@Metz](https://openziti.discourse.group/u/Metz)\
**Post date:** [September 15, 2023, 11:35am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/6 "2023-09-15T11:35:27Z")

</div>

Does the proxy mode still exist? `ziti-edge-tunnel help` does only show `run` and `run-host` mode.

I like to run a sidecar container without priveleged access rights and therefore I like to use the tcp proxy mode.

I see the `openziti/ziti-tunnel` image but I miss a description in the comtainer documentation [Containers | OpenZiti](https://openziti.io/docs/reference/tunnelers/linux/container/)

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [September 15, 2023, 11:53am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/7 "2023-09-15T11:53:00Z")

</div>

Hi @Metz, yes. The `ziti tunnel proxy` command still exists. When you say "sidecar," are you referring to a K8S pod or more generically, e.g., a Compose service?

---

<div class="post-metadata">

**Author:** ![Metz](https://avatars.discourse-cdn.com/v4/letter/m/c77e96/32.png) [@Metz](https://openziti.discourse.group/u/Metz)\
**Post date:** [September 15, 2023, 11:55am UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/8 "2023-09-15T11:55:48Z")

</div>

today I'm still using docker-compose. But plan in future to move to k0s or k3s.  
Is there an docker image available for the ziti-tunnel with proxy mode?

---

<div class="post-metadata">

**Author:** ![qrkourier](https://yyz2.discourse-cdn.com/free1/user_avatar/openziti.discourse.group/qrkourier/32/52_2.png) [@qrkourier](https://openziti.discourse.group/u/qrkourier)\
**Post date:** [September 15, 2023, 12:29pm UTC](https://openziti.discourse.group/t/ziti-tunnel-proxy-vs-tproxy-vs-host-configurations/573/9 "2023-09-15T12:29:29Z")

</div>

For this use case, you want the `openziti/ziti-tunnel` image because its `entrypoint.sh` has helpful functionality for enrollment. The image is produced from [this Dockerfile](https://github.com/openziti/ziti/blob/release-next/dist/docker-images/ziti-tunnel/Dockerfile) whenever `ziti` is released. It's a thin veneer over the minimal `ziti-cli` image which itself merely provides the `ziti` executable.

You can provide any `ziti tunnel` sub-command as an arg to the `openziti/ziti-tunnel` image, i.e., `proxy`, `tproxy`, or `host`.

The `proxy` sub-command fits your use case because it does not require elevated privileges. However, this does introduce a bit of fragility because you must continually ensure the client proxy's bound services and ports are aligned with the dialing application.

Here's an excerpt from [the K8S sidecar example](https://openziti.io/docs/guides/kubernetes/workload-tunneling/kubernetes-sidecar/) that illustrates the env vars and paths you must configure for this container image. You can adapt this to use your desired sub-command instead of `tproxy`, and remove the additional capability `NET_ADMIN` since it's not necessary for `proxy`.

```yaml
        - image: openziti/ziti-tunnel
          name: ziti-tunnel
          args: ["tproxy"]
          env:
          - name: ZITI_IDENTITY_BASENAME
            value: sidecar-client # the filename in the volume is sidecar-client.json
          volumeMounts:
          - name: sidecar-client-identity
            mountPath: /netfoundry
            readOnly: true
          securityContext:
            capabilities:
              add:
              - NET_ADMIN

```

You could use the same solution when you migrate to K8S, but there's not yet a Helm chart focused on this use case. There is, however, an established pattern for doing this with the `openziti/ziti-router` chart, which has the `ziti tunnel` features on-board when the router is created with tunnel mode enabled. Convenient, right?

I haven't mentioned this use case for the router yet in [the K8S workload tunneling overview](https://openziti.io/docs/guides/kubernetes/workload-tunneling/#intercepting-pod-egress) (I'll take an action to add that), but there's a section in [the router chart's README](https://openziti.io/docs/guides/kubernetes/hosting/kubernetes-router#proxy-tunnel-mode) about using `proxy` mode as a cluster service, optionally with Ingress.
