We can see a bigger amount of TLS than we have in TCP frames on the ziti0 loopback, can you tell me what kind of information are generally sent between the tunnelers and the ziti edge router?
Also, at the end we can see that zhost1 closed itself its connection on the ziti0 loopback without even communicate with the router, is that for the user experience or else ?
Ziti Mobile Edge (iOS) - #12 by scareything In the diagram in this post, @scareything covers the TCP interaction (SYN -> SYN/ACK) between a host and tunneler ("Ziti Mobile Edge" and ziti-edge-tunnel as the tunneler in the sequence diagram)
Connection Security | OpenZiti The top two diagrams cover the independent mTLS links and the end-to-end encryption added by the app endpoints (meaning, "apps that include a Ziti SDK, such as any of the tunnelers")
Data Flow Explainer | OpenZiti include high level data flow among controller, routers, and SDK endpoints (such as the tunnelers).
@scareything will be able to go deeper on the host/tunneler interactions, but I believe he's out-of-pocket for the next few day.
can you tell me what kind of information are generally sent between the tunnelers and the ziti edge router?
zhost1 closed itself its connection on the ziti0 loopback without even communicate with the router
I'd say your understanding of what's going on at the TCP layer is pretty good. Generally the TLS Connections between the tunnelers and egde routers carry the edge protocol. It includes commands like:
"dial a service", which you see for example when a tunneler initiates a connection on the openziti network after a SYN is intercepted
"dial succeeded" (or "dial failed"), which is sent in response to a dial request
data messages, which for example contain the payloads (and only the payloads, not the seqno, etc) from the TCP/IP PSH segments that the intercepting tunneler receives.
So the tunnelers are each having totally separate TCP conversations at their respective end of the end-to-end connection. Everything that happens in the TCP connections is expressed as an OpenZiti edge message to the other tunneler. The combined sequence is something like this:
curl sends SYN to the IP for http.ziti
the tunneler on zhost1 receives this SYN, if it can match the dst IP:port of the SYN with an OpenZiti service then it will send a dial request to the controller on the TLS connection for that service.
the controller determines that the best destination for this dial is the tunneler on zhost2 that has already binded the service
the tunneler on zhost2 receives the openziti dial request and attempts to connect to the address in the host.v1 service configuration. the status of the connection between zhost2 and the web server is expressed back to the zhost1 tunneler (over TLS) in the form of a "dial succeeded" or "dial failed" message.
when the zhost1 tunneler receives the dial succeed message it sends the TCP SYN/ACK to curl
curl then sends the HTTP GET over TCP. the zhost1 tunneler extracts the payload from the TCP packet and sends it as a data message over the openziti (TLS) connection.
The zhost2 tunneler receives the data message and sends its contents to the http server over the TCP connection that it established in step 4.
the zhost2 tunneler reads the response from the HTTP server and sends it as a data message over the openziti (TLS) connection.
i'm not sure if you watched the packets on zhost2. if you did you would have seen the http server also sent a FIN to the zhost2 tunneler, which would be expressed to the zhost1 tunneler as a "connection closed" message over TLS.
the zhost1 tunneler receives the data message followed by the close message, and proxies them to curl in the form of TCP PSH and FIN packets.
Please let me know if this doesn't make sense, or doesn't answer your question.
Sorry for the late response. This is exactly what I was looking for.
Your explanation helps me to better understand how packets transit between tunnelers.
I noticed a very good security point with OpenZiti: we can configure a firewall to drop all packets that try to initiate a NEW connection to any tunneler (useful if we embed tunneler with the host that send/receive packets). That reduces a lot the attack surface, none non-enrolled device can communicate with enrolled hosts in order to access a web service, ssh connection and so on.
For example with iptables:
# Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
# Accept on localhost
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
# Allow established sessions to receive traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
