Package Details: cloudflare-warp-bin 2026.4.1350-1

Git Clone URL: https://aur.archlinux.org/cloudflare-warp-bin.git (read-only, click to copy)
Package Base: cloudflare-warp-bin
Description: Cloudflare Warp Client
Upstream URL: https://1.1.1.1
Licenses: unknown
Conflicts: cloudflare-warp
Provides: warp-cli, warp-diag, warp-svc
Submitter: solatis
Maintainer: solatis (mhdi, billyaddlers, vk8a8, Neomax7)
Last Packager: mhdi
Votes: 74
Popularity: 1.71
First Submitted: 2021-05-26 08:59 (UTC)
Last Updated: 2026-05-12 09:19 (UTC)

Latest Comments

1 2 3 4 5 6 .. 20 Next › Last »

SolarEclipse4294 commented on 2026-05-18 10:26 (UTC)

The latest update introduced a missing dependency: libayatana-appindicator (provides libayatana-appindicator3.so.1). The new version of warp-taskbar is dynamically linked against it, but it is not listed in depends=(), so it doesn't get pulled in automatically on update. warp-taskbar fails immediately at launch with:

error while loading shared libraries: libayatana-appindicator3.so.1: cannot open shared object file: No such file or directory

Manually installing libayatana-appindicator resolves it. Please add it to the dependency list.

rncoll7 commented on 2026-05-13 14:09 (UTC)

WARP not resolving private / Zero Trust DNS on Arch (returns public IPs)
Symptom

With warp-cli connect succeeding, hostnames protected by your Cloudflare Zero Trust policy (e.g., private AWS RDS, internal-only services) still resolve to their public IPs instead of the WARP gateway IP (in the 100.64.0.0/10 range). Result: connections to private resources time out even though the tunnel is up.

Quick check:

warp-cli connect
getent hosts <your-zero-trust-host>
# If it returns a public IP instead of 100.64.x.x / 100.80.x.x, you're affected.
Root cause

This package does not enable systemd-resolved, and Arch's default NetworkManager writes /etc/resolv.conf directly with whatever DNS servers it has — usually the ones from your Wi-Fi connection (8.8.8.8, your router, etc.).

The WARP daemon listens on 127.0.2.2 for split-horizon DNS, but nothing on the system actually queries it — so all DNS queries bypass WARP and hit your regular resolver, which returns the public IP.

On Ubuntu this works out-of-the-box because systemd-resolved is enabled by default and /etc/resolv.conf is already a symlink to its stub. On Arch you have to wire this up yourself.

Fix
# 1. Enable systemd-resolved
sudo systemctl enable --now systemd-resolved

# 2. Point /etc/resolv.conf at the resolved stub
sudo ln -sf /run/systemd/resolve/stub-resolv.conf /etc/resolv.conf

# 3. Tell NetworkManager to delegate DNS to resolved
sudo install -d /etc/NetworkManager/conf.d
sudo tee /etc/NetworkManager/conf.d/dns.conf >/dev/null <<'EOF'
[main]
dns=systemd-resolved
systemd-resolved=true
EOF

# 4. Remove any hardcoded DNS on your active connection
#    (replace "MyWifi" with the name from `nmcli connection show --active`)
sudo nmcli connection modify "MyWifi" ipv4.dns "" ipv4.ignore-auto-dns no
sudo nmcli connection modify "MyWifi" ipv6.dns "" ipv6.ignore-auto-dns no

# 5. Restart NetworkManager and reconnect WARP so it re-registers its resolver
sudo systemctl restart NetworkManager
warp-cli disconnect && sleep 2 && warp-cli connect
Verify
resolvectl status | grep "DNS Server"
# Should show 127.0.2.2 / 127.0.2.3 on the CloudflareWARP link.

resolvectl query <your-zero-trust-host>
# Should now return an IP in 100.64.0.0/10 instead of the public one.
Optional: keep a public DNS fallback when WARP is off

Add it to systemd-resolved (not to NetworkManager) so it doesn't clash:

sudo tee /etc/systemd/resolved.conf.d/fallback.conf >/dev/null <<'EOF'
[Resolve]
FallbackDNS=1.1.1.1 8.8.8.8
EOF
sudo systemctl restart systemd-resolved
Scope

This only affects users with Zero Trust split-horizon DNS / private resource access (the Cloudflare admin pushes a network policy that maps internal hostnames). Plain consumer WARP works fine without these steps.

danirod commented on 2026-04-11 16:38 (UTC)

Until this package gets updated, if anyone needs to use the latest version, can take the version number and updated SHA-256 hash from the official metadata file for noble (the PKGBUILD script builds the package by extracting it from the noble .deb file): https://pkg.cloudflareclient.com/dists/noble/main/binary-amd64/Packages

As of Apr 11 2026, that is 2026.3.846.0 with the SHA-256 checksum d522932b4416fb709ca812ea1db22c3e7cbfe9e9328d97bda9172360e327479f

RatAnon commented on 2025-11-20 04:35 (UTC)

This isn't working for me. Fails with a daemon/warp-svc.service crash within 5 seconds. Tried to read journalctl, found rust stacktrace.

craight commented on 2025-08-21 17:39 (UTC) (edited on 2025-08-21 17:40 (UTC) by craight)

hi, i'm looking for a way to export the sslkeylogfile for the warp client in order to decrypt and inspect the quic traffic of the connection setup. Any idea how to accomplish this?

wang1zhen commented on 2025-06-09 05:55 (UTC)

could the logout bug be fixed from upstream as per @bzylstra?

bzylstra commented on 2025-04-26 15:59 (UTC)

The Logout bug is caused by the warp-taskbar service binding to the graphical-session.target. You can fix this by replacing BindTo with PartOf=graphical-session.target in the /usr/lib/systemd/user/warp-taskbar.service file.

arvigeus commented on 2025-03-26 07:34 (UTC)

Note: Installing this package breaks Logout functionality (tested on KDE). Disabling/Stopping warp-svc won't work because warp-taskbar remains active. As workaround you can install cloudflare-warp-nox-bin.

Davidasx commented on 2025-01-07 13:23 (UTC)

@solarisfire Please sudo systemctl enable warp-svc.service and try again.

solarisfire commented on 2024-12-23 09:17 (UTC)

Installed this last night.

I now just get a zero trust window saying "The Cloudflare Warp service is not available. Try rebooting."

Rebooting does not help.

1 2 3 4 5 6 .. 20 Next › Last »