You got it. Locally on that tunneler client, with OpenZiti running, will intercept the request for “your.private.server” and it’ll get assigned to a 100.x.x.x IP (for example, 100.64.0.3). That IP is then captured by the OpenZiti client. So your browser ends up sending traffic from 73.5.5.5 to 100.64.0.3 (via the DNS lookup to “your.private.server”).
That’s when the OpenZiti client maps the packets landing at “100.64.0.3” to “your.private.server” and wraps the packets in OpenZiti routing protocol and puts those OpenZiti packets onto the overlay.
The overlay knows that the offload point for “your.private.server” is “the office” and routes the traffic to “the office”. Once there the tunneler in “the office” knows that it’s traffic for “your.private.server” and it knows that it needs to make a TCP connection to the configured offload target (the actual remote server). That traffic then exits “the office” from 8.8.8.1, allowing the traffic to land at the private server and make it through the IP-based ACL.
Since the tunneler initiated the outbound connection, there’s no NAT to worry about (the underlay handles all that as it would normally).
Hope that all makes sense! 