I saw the upcoming proxy.v1 config type coming up in v1.7, which inspired me to experiment with creating a reverse proxy using ziti-prox-c to forward traffic do a container running on a destination machine (which is running ziti-edge-tunnel).
Here’s a super rough diagram:
My question is: Is it possible to preserve the client IP so that it’s presented correctly to the podman container. I’m forwarding raw TCP rather than HTTP(S) so I can’t utilise HTTP headers etc. I’ve searched through the forum and GitHub issues - the closest thing I’ve found is setting the source IP in the service’s intercept config, but that doesn’t apply here.
Would anyone be able to point me in the right direction? From this and this I’m suspecting I may need to experiment with zfw?
You should be able to do this if you use ziti-edge-tunnel on both sides of your tunnel (using the sourceIp field in your intercept.v1 configuration). ziti-prox-c doesn’t even look at the service configurations (which I’m guessing is why you mentioned the intercept config “doesn’t apply here”?)
From what you’ve shared here I don’t think ziti-tunnel-sdk-c#443 is relevant, since it doesn’t look like your service needs to have connections being intercepted on both sides of the tunnel.
Is there a reason that you aren’t using ziti-edge-tunnel?
Does ziti-edge-tunnel have a opaque proxy similar to ziti tunnel proxy? That's what I'm using ziti-prox-c for at the moment.
How are you categorizing ziti tunnel proxy as “opaque”? I tend to think of it more as a “transparent” proxy, because you don’t need to tell applications to specifically use it e.g. as a proxy server.
I might just be using the wrong terminology - I’m exposing a specific service on a specific port. In my case I want to expose test-service on port 443 externally so that clients can connect to it over the internet via the public IP address.
