Each tunneler will establish it's own TCP session with a router first. The remote tunneler will establish an independent TCP session to whatever target it's instructed to. So the TCP sessions are entirely independent.
OpenZiti tunnelers specific function is to tunnel bits, not IP packets. So in the client side tunneler, the actual payload is extracted and put onto the overlay not the IP packet. The overlay then routes the payload to the termination point on the OpenZiti overlay. In this case, that's another tunneler. When the data arrives at the destination tunneler, there's configuration (host.v1/v2) that instructs the tunneler what to do with the payload. Here, the instruction is "open s new TCP session to. IPv6 address and send this data".
Does that clear it up or did I miss something in your question?
The tunneler intercepts traffic using TUN and passes the intercepted packets to the lwIP stack via the netif_shim_input function. During this process, the packets are converted to the pbuf_raw layer. Does this mean that the intercepted traffic discards the packet headers?
After processing, the packets are forwarded from the protocol stack to the virtual network interface using the netif_shim_output function. In this step, the output is encapsulated as a pbuf_transport layer. Does this step encapsulate the protocol, IP, and port? Or is the encapsulated data still just the payload?
The header information from intercepted packets is ultimately discarded, but not at the point you're referring to. netif_shim_input reads the packet (bytes) from the tun interface and passes the bytes to on_packet. It's also helpful to know that lwip's pbuf type supports the concept of pointing at (and having space for) different layers.
on_packet allocates a RAW pbuf for interacting with lwip and copies the packet bytes into it (with pbuf_take). If the allocation and copy are successful, the pbuf, which still contains the IP header, is passed to lwip via netif->input (which was previously set up to point to ip_input()
ip_input() figures out if the packet is UDP or TCP and calls the appropriate receive callback that's implemented by the tunneler SDK (that will be recv_udp or recv_tcp). These receive functions inspect the packet header to determine if it maps to one of the ziti service intercept configurations that the tunneler is aware of, and if so a new overlay connection is created.
It's possible that the received packet is already associated with an intercepted connection - in which case the receive function passes the packet back to lwip where it will be dispatched to the appropriate data callback on_udp_client_data or on_tcp_client_data. The data callbacks receive a pbuf that is pointing to the payload of the originally received packet. The header information isn't all that helpful here, since lwip also calls the data callback with the IP connection that the packet is associated with. At this point the only thing that needs to happen is to write the payload to the associated ziti connection.
netif_shim_output is the function that we've told lwip to call when there is data that needs to be delivered on intercepted connections. When lwip calls netif_shim_output, it passes a pbuf that's pointing at the IP layer. By the time lwip calls this function, it has constructed a complete IP packet using the connection information and the payloads that are sent in tunneler_udp_write and tunneler_tcp_write.
