So we're all supposed to be sold on this "Zero Trust" future where every packet gets inspected and routed through a dozen global anycast nodes, and then we hit the most basic, mundane enterprise task: printing. And it breaks. Hilariously, predictably.
I've been running a proof of concept for Cloudflare One with the WARP client, and we've hit a wall that feels like a throwback to the VPN problems of the 1990s. A specific subset of users, when WARP is active, cannot print to designated network printers. These aren't cloud printers; they're traditional on-prem devices with IP addresses in the 10.x.x.x range. The traffic should, in theory, be split-tunneled if the routes are set correctly, but something in the stack is interfering. The moment we disconnect WARP, printing resumes instantly. This isn't a driver issue or a print spooler restart fix.
The real kicker is the inconsistency. It's not all users, and it's not all printers. It seems to correlate with older print servers or printers using specific protocols (LPD, some raw port 9100 traffic), but I've seen it affect a modern Kyocera fleet model too. The common thread is the local network segment. This suggests that the WARP client's virtual interface or the Cloudflare gateway's traffic inspection is mangling the packets or blocking the necessary broadcast/multicast discovery protocols (like WS-Discovery). I've tried the obvious: adding the printer subnets to the split tunnel exclude list in the Zero Trust dashboard, setting policies to bypass for the printer IPs, and even creating a "Do Not Inspect" policy for the destination IPs. The results are mixed, which points to a deeper issue with how WARP handles layer 2-adjacent traffic once it grabs the default route.
Has anyone else torn their hair out over this? I'm particularly interested in the actual packet flow. Is WARP intercepting *all* traffic at the client level before the split tunnel logic is applied, perhaps causing ARP to fail? Have you had to deploy GPOs or scripts to disable WARP for certain subnets or applications as a workaround? I see a lot of glossy marketing about replacing your legacy VPN, but not a lot of deep dives into the gritty, real-world compatibility problems like this one. The total cost of ownership just got a whole lot higher if my help desk is flooded with "I can't print" tickets because we wanted to add another layer of security theater.
Just my two cents
Skeptic by default
Oh yeah, the classic "this should work in theory" versus "it works for Karen in Accounting but not for Bob in HR" problem. We saw something similar, though ours manifested with scanning to network folders, not printing. The split tunnel config looked perfect on paper.
Our fix was weirdly specific. We had to add the printer's IP, the print server, and the broadcast address for that subnet to the split tunnel exclude list. Just the printer IP alone wasn't enough for some of the older devices. It was like they needed to chat with the local network neighborhood first. Might be worth a shot? The inconsistency you're seeing sounds painfully familiar.
That broadcast address tip is a good call, I wouldn't have thought of that. It makes sense for discovery.
We had a similar fix, but with a twist. For our older Konica devices, we also had to exclude the whole mDNS multicast range (224.0.0.251) from being routed through WARP. Even with the printer IP and server excluded, some of the initial "find me" chatter was being captured, which broke the process. Adding that as a separate exclusion rule in our split tunnel policy did the trick.
Makes you wonder how many other local discovery protocols get tangled up.
Migration is never smooth.
That mDNS multicast range is such a sneaky one. It makes total sense that those discovery packets would get scooped up by WARP if they're not explicitly excluded.
We ran into something almost identical with a fleet of legacy Xerox workgroup printers. Even after splitting the tunnel for the IP, they'd fail to spool. Your comment about the "find me" chatter hits the nail on the head. For us, it wasn't just mDNS, we also had to exclude a local LLMNR port for a few truly ancient devices. It's like each printer generation has its own little handshake ritual that breaks in these new tunnels.
Really makes you think about the hidden "legacy tax" in these modern Zero Trust rollouts, doesn't it? All those little local protocols we forgot about.
The broadcast address piece is crucial, and I see it in logs constantly. Adding just the printer IP creates a silent failure because the client still tries, and fails, to send discovery or status packets to the broadcast address.
It's not just older devices either. I've seen modern "enterprise" printers that use broadcast for queue status checks. The fix you described is correct, but it highlights a gap in most split tunnel documentation, which treats destinations as static unicast endpoints. Real local traffic isn't that clean.
Always verify the exclusions are actually taking effect on the endpoint. I've seen policies deploy but the client fails to apply the local route until a restart.
Where is your SOC 2?
Oh man, that inconsistency you mentioned really hits home. We just started learning about Zero Trust at my bootcamp and I wouldn't have even thought about the old printing protocols causing a headache like this.
It sounds like the split tunnel is catching the main IP traffic but missing all the little background chatter the printer needs to work. That would explain why it's so random, right? Some devices just need more of that local talk.
Thanks for posting this, it's a great real-world example of the weird gaps between theory and practice. I'll definitely remember this for when we start our WARP pilot.