It's a simple use case, but I can't seem to find an elegant solution
I have some hardware which sends status to a configured IP:port. I can't change the hardware; only update its configuration options.
I've made the status service dark using OpenZiti and now I want to hook my hardware into it.
I've set up a gateway host on the hardware's local network, and it has a Tunneller connected into OpenZiti.
Now what?
I'd like to create an intercept that listens to a port on the gateway host, and forwards to the status service via OpenZiti.
The problem is that all the configurations I've tried use name resolution to access the service. These are meant for localhost and are not available to other machines via the local network.
Any suggestions?
I've found some related entries:
- There's a feature request relating to the SDKs to avoid intercepting local packets. That would work here too. I'm not using an SDK, but the use case seems applicable.
- I could create an edge router with the tunneller in proxy mode, but that would affect all services, not just this one. I'd like to leave other services unaffected.
- There is a documented solution that changes the name resolution on the hardware generating the messages, so that it can use the zitified domain name to access the tunneller service on the gateway host. This won't work for me as I can't change the hardware; and even if I could the solution is very sensitive to the OS being used by the hardware.
- I could write a little program to proxy connections from a local port and pass them on to the tunneller. This would work but I've quite a few flavors of hardware and I'll end up with quite a lot of them.
- I could update the little program so it is ziti-native; listens to a port and passes directly into OpenZiti. I'll end up with quite a few of these and they will need separate Ziti identities; it's not great.
I'm favoring the option to use a little program to forward traffic on to the tunneller as I can see it would work. But a fix to the tunneller would be preferable.
For clarity, here's my test cases
I've two services that bind to the same service provider.
The first service defines an interceptor for 'test.test' port 811. I can telnet test.test 8111 and it works. But this is not available from other machines on my local network.
I want to use the second service as telnet localhost 8111, but I can't figure out how to set up the interceptor to make this happen. If I can get this working I ought to be able to open port 8111 in my firewall for use by other hardware on my local network.
One more question, what protocol is the hardware using? Is it TCP, UDP, HTTP? I think there are a few different options depending on what the protocol is. Also, did you find the guide on using a router as a zero trust gateway? Use a Router as a Local Gateway | OpenZiti
Just plain TCP, data content is hardware specific.
I found that guide. It's the option I mentioned that tweaks routing rules on the Windows Client at 172.16.31.174. That won't work for me as I can't modify the hardware.
The relevant section for Windows Client modification is here
FYI - this is part of something I'm working on to allow OT to be connected to services made dark using OpenZiti.
It's a general OT problem, especially legacy equipment. The messages typically contain status and alerts.
The ziti CLI has functionality that allows you to run it as a service proxy. The command still exists, but was hidden a long time ago when ziti-edge-tunnel came to be. I generally discourage mentioning it, just because it's something that we had previous planned to move away from but until we have a proxy-type solution like this, we left it around just in case....
This seems like a "just in case" type of moment. If you run ziti tunnel proxy you'll see you can use a service name and port. That will surface the particular service (by name) on that particular port.
For example if you run:
ziti tunnel proxy --identity ${identityFile} ${serviceNameHere}:1234
You'll see a log similar to:
[ 0.088] INFO ziti/tunnel/intercept/proxy.(*interceptor).handleTCP: {service=[mgmt] addr=[0.0.0.0:1234]} service is listening
This port is open to any TCP traffic so just beware of that but since we build the ziti cli for numerous architectures, it might work for you?
Interesting!
I hadn't mentioned that my edge gateway is actually Windows with ZDEW installed, so this won't work trivially.
I didn't want to constrain the solution as I suspected the gateway host will be installed on whatever is lying around. For example, I talked recently with a company who are using a Windows host as a jump server for accessing their OT, and if they go the Ziti route I suspect they would prefer to add ZDEW to their jump server rather than get a new Linux host as their firewall and network segmentation rules are already set up.
Also, this solution requires an identity to work. I mentioned this as a potential problem for a Ziti native application doing the port forwarding as we could end up with a lot of extra identities.
FYI - I've been researching the port forwarding application approach.
I found this Python port forwarding application, and it seems to work!
It supports multiple ports, so only one instance is needed for all the OT needing to send messages to Zitified services.
There's a bit of latency added to connection creation and I'm not sure where that is coming from. But at least I can prototype connecting OT to Zitified services.
Cool I'm glad you got something that would work for you.
FWIW, Windows also lets you do something like this, if that's interesting:
netsh interface portproxy add v4tov4 listenport=1234 listenaddress=0.0.0.0 connectport=8441 connectaddress=192.168.100.200
This would allow you to basically accept on any IP on port 1234 and send it to the IP of your choice. Couple this with an intercept from ziti to intercept that IP (not the hostname) and it would do the same thing. Might be simpler for you...
Thanks - that's a new one for me!
I'll give it a go