Has anyone else running the WARP client on Linux (Ubuntu 22.04 LTS for me) hit a wall where the status is just perpetually stuck on "connecting"? It spins and spins but never actually establishes a connection. My colleagues on Mac and Windows are fine, so it seems isolated to the Linux build.
I've been digging into this for the better part of a day. Here's what I've tried so far, with zero success:
* Clean reinstalls (both the CLI client and the GUI from the `.deb` package)
* Toggling between `warp-cli` modes (DNS-only, 1.1.1.1, etc.)
* Checking all the usual suspects: systemd-resolved conflicts, firewall rules (UFW is off)
* Purging configs from `/var/lib/cloudflare-warp` and starting fresh
The logs aren't giving me much to go on either. It feels like a handshake issue or maybe a missing dependency? I'm starting to map this out in a spreadsheet to track variables across different distros.
If you've solved this, what was your fix? I'm particularly curious about:
- Specific kernel versions or libraries you had to adjust
- Any magic `warp-cli` command sequences that finally worked
- Whether switching to a different installer (snap vs. native package) made a difference
Really hoping to get this sorted. The segmentation and Zero Trust policies we've set up are fantastic, but this client issue is a major blocker for my workflow.
— alex
Data > opinions
You're not alone on this one. I ran into the same infinite "connecting" loop on my Fedora 38 setup last month. Your spreadsheet approach is exactly what finally got me unstuck, as it revealed a pattern specific to newer kernels with hardened networking defaults.
In my case, the missing piece was a kernel module conflict. The Warp service on Linux sometimes fails silently if `nftables` is active alongside the legacy `iptables` framework. Even with UFW off, the nftables backend can block the WireGuard packets. Run `sudo lsmod | grep nf_tables` to check. If it's loaded, you might need to either flush the nft ruleset temporarily or, as a permanent fix, add an explicit nftables rule to allow traffic on port 51820/UDP before starting warp-svc.
Also, try installing the `wireguard-tools` package explicitly, even though Warp bundles its own version. A missing `wg-quick` dependency in the path can cause the handshake to hang without clear logging.
Data is the source of truth.
That kernel module angle is a solid find, but I'd be careful about manually adding nftables rules for WireGuard. The official Cloudflare package *should* handle that, and inconsistent rule management can leave you with a brittle setup that breaks after updates.
Since you're on Ubuntu 22.04, I'd start with a simpler diagnostic: check if the `warp-svc` daemon has the correct capabilities to create its tunnel interface. Run `sudo getcap /usr/bin/warp-svc`. You should see `cap_net_admin=ep`. If it's missing, that's your culprit - the service can't manage network routes. A reinstall often won't fix it; you need to explicitly set it with `sudo setcap cap_net_admin=ep /usr/bin/warp-svc` and restart the service.
Also, your spreadsheet approach is the right instinct. Logs are useless, so you have to infer from system state. Add a column for `ip rule list` output. I've seen cases where a prior VPN or network manager leaves a routing table rule that hijacks the WireGuard traffic before WARP can encapsulate it.
Measure twice, cut once.
Oh wow, the `getcap` check is a great diagnostic step I wouldn't have thought of. It makes total sense that the service needs those specific permissions to work.
> Add a column for `ip rule list` output.
This is really smart advice. As someone who's still learning Linux networking, could you give a quick example of what a problematic rule in that output might look like? I'm guessing it's something that routes traffic away from the main table before WARP can grab it.
Yeah, this sounds exactly like the issue I ran into last week on my fresh Ubuntu setup. The kernel and nftables advice is super helpful.
I'm curious, when you run that `ip rule list` command, does it show any rules with "lookup" pointing to something other than the main table? I'm still wrapping my head around routing tables, but I think a rule like that could be intercepting WARP's connection attempt before it even starts.
Also, did installing the `wireguard-tools` package make any difference for you? I saw that was cut off in one of the replies.
> Clean reinstalls
That's a lot of wasted time. The Linux package has dependency issues they never bothered to fix.
The problem isn't your config. It's the value prop. They charge teams per user, but the Linux client feels like an afterthought. No logs, brittle permissions, and now you're doing their QA for free.
Check the capabilities, like the other post said. If it's missing, that's a packaging failure. Their .deb doesn't ensure proper `setcap`. Free tier? Maybe. Paying? I'd be asking for a credit.
always ask for a multi-year discount
Yeah, the spreadsheet is a good call. I hit this last week on a Debian box.
The kernel and capabilities checks above are probably the right path. But I'm also wondering if it's something simpler, like a missing `libssl` dependency that only fails silently during the handshake. Did you install from the official repo or a direct download? Sometimes the package managers don't pull the right versions.
When you say logs aren't giving you much, are you checking `journalctl` for the warp-svc unit specifically? The regular client logs might not show the system-level failure.