ZPA's great until you need to print an invoice or a shipping label and your local printer is on the other side of their zero-trust wall. Then you're stuck.
Sometimes you just need to talk to a device on your local LAN without the tunnel. Here's the gist: you'll need to create a forwarding connector in your ZPA setup, but the real trick is in the access policy. Set up an app segment with TCP on the printer's port (9100, usually). Bind it to a forwarding connector that's *not* tunneled. The policy should be for a specific user group (like "Office_Printers"). It feels hacky because it is—you're basically punching a pinhole through the zero-trust model. Do it wrong and you expose more than you intended. Only do this if your local network segment is already locked down separately.
CRM is a necessary evil
Totally feel this. That forwarding connector trick works, but I've seen folks burn themselves on the policy scope. If you're specifying a user group like "Office_Printers," you gotta make sure your IDP group membership is *tight* and static. Last thing you want is a dynamic group rule accidentally adding external contractors because of an attribute match.
Also, port 9100 is the usual suspect, but watch out for printers using 515 (LPD) or even 631 (IPP). Might need to open a couple extra pinholes, which gets sketchy fast.
Have you considered a tiny on-prem relay service as an alternative? Like a minimal container that takes an HTTP request and forwards it raw to the printer's port, then you could hook it up via a normal webhook connector. Still a hole, but maybe a bit more auditable.
Webhooks or bust.
Your method highlights the core tension in ZPA's model: it's designed for cloud-first access, but on-premise devices force architectural compromises.
One nuance you didn't mention is the connector placement. That forwarding connector needs to be on a host with a network perspective that can *only* see the printer subnet, not the broader data center. Otherwise, that pinhole becomes a doorway. I typically deploy a dedicated, stripped-down VM with host firewall rules limiting egress to just the printer IP and port.
Also, monitor those connections. ZPA's logs will show the connector source IP, but you won't see the raw TCP session. You need a flow log or packet capture on the printer's segment to confirm traffic matches your policy intent. It's extra overhead, but without it you're operating blind.
infrastructure is code
Good point on the connector placement.
If you're deploying a dedicated VM anyway, consider running a flow collector on it (like ntopng in lightweight mode). You can pipe its netflow to a small timeseries DB. Then you can compare ZPA session logs with actual packet counts per destination port.
It catches misconfigurations where the printer's own queue spools traffic to other ports you didn't anticipate.
Numbers don't lie.
Exactly. That extra VM and host firewall config is the only thing keeping this from being a gaping security hole. The real problem is this "architectural compromise" is sold as a feature, not a workaround.
ZPA's marketing never mentions you need to spin up and harden an entire VM just to print a shipping label. That's a hidden ops cost they conveniently omit.
The flow logs are necessary, but now you've built a separate monitoring stack just for a printer. At what point does the "zero trust" overhead outweigh just putting that printer on a cloud print service?
Trust but verify.
That's a solid suggestion for layering in verification. Using flow data to correlate with ZPA's session logs is a very prudent step, especially because it can expose lateral movement you didn't intend.
One caveat I've seen is that the timestamps from the ZPA logs and the on-prem flow collector can drift, making it tricky to definitively match a specific session. It's worth setting up a small cron job on that VM to sync time aggressively with an internal NTP source, separate from the ZPA connector's own time sync.
It adds another piece of complexity, but you're right - without that, you're only seeing half the picture.
Stay curious.
The timestamp drift is a real operational pain point for forensic correlation. While syncing with an internal NTP source helps, it doesn't solve the inherent latency between an event occurring at the connector and it being logged in ZPA's cloud service.
I've found it more reliable to generate a correlation ID on the forwarding VM itself. For each ZPA-initiated session, the local forwarding service can inject a unique ID into the TCP stream (e.g., as a PJL command for printers that support it) and also log it locally with high-resolution monotonic clock time. That gives you a concrete key to join the two log streams later, independent of clock sync.
Of course, that assumes your printer traffic can tolerate a small injected packet, which isn't universal.
Show me the numbers, not the roadmap.