Step-by-step: Creating a ZPA application segment for a TCP-based internal tool.

Okay, so I've been knee-deep in ZPA for the last week, trying to get some of our internal monitoring tools accessible securely. The goal? Expose a TCP-based internal admin tool (think something like a `netdata` or `pgAdmin` server) without a VPN. Figuring out the exact steps for a TCP app segment was trickier than I expected compared to HTTP.

Here's the step-by-step that finally worked for me. The key is remembering ZPA treats TCP segments a bit differently—it's all about the port, not a hostname.

**Prerequisites:**
* ZPA Admin Portal access (obviously)
* Your App Connector set up and showing as "Healthy" in the ZPA cloud.
* The internal IP and port of your tool.

**Step 1: Create the Application Segment**
Navigate to **Administration > Application Segments** and click **Add Application Segment**.
* **Segment Name:** Something clear like `tcp-internal-monitoring-tool`
* **Description:** (Optional, but I always add one) "TCP access to internal NetData server on port 19999"
* **Enabled:** Checked.
* **TCP Port Range:** This is crucial. Enter your port, e.g., `19999`. For a single port, put it in both start and end fields.
* **Domain:** Leave this blank. For TCP, you'll connect via the IP defined in the Server Group.

**Step 2: Configure the Server Group**
This is where you point to your actual internal server.
* Either select an existing group or create a new one (e.g., `servers-monitoring`).
* When adding/editing a server in the group:
```yaml
Server Address: # e.g., 10.10.10.50
Port: # e.g., 19999
```
* Link this Server Group to the Application Segment you just created.

**Step 3: Set up the Access Policy**
Go to **Administration > Access Policy** and create a new rule.
* **Rule Name:** `allow-eng-to-monitoring-tool`
* **Action:** `Allow`
* **Policy Type:** `Access Policy`
* **Conditions:**
* `App Segment` == `tcp-internal-monitoring-tool`
* `User Segment` == `engineering` (or whatever group needs access)
* **Default Rule:** Should be `Deny`.

**Step 4: Testing and Gotchas**
Don't use a browser to test. Use a native TCP client. For my netdata example, I'd point my local netdata client to the ZPA-provided domain (you can find it in the segment details after provisioning). The connection will be brokered through the App Connector.

Biggest pitfall I hit? **Forgetting to add the Application Segment to the App Connector Group's policy.** Double-check that under **Administration > App Connector Groups**, your connector group has the new segment listed in its "Associated Application Segments."

Also, latency visualization here is interesting. You'll see the TCP handshake times in the ZPA dashboard, but for real performance insights, you'll still want your own internal monitoring on the app itself. Anyone else set up something similar and compared TCP vs. HTTP segment performance metrics in their observability stack?