Apply regenerates WARP wgcf profile without Table=off/DNS protections → wg-quick fails (no resolvconf) or hijacks all routing → public lockout #5569

Activity

1. firexrwt commented on Sep 27, 2026

   

   firexrwt

   on Sep 27, 2026

   More actions

   Hit this on 13.0.3 (upgraded from 12.3.x, Ubuntu 22.04, no resolvconf): after an apply, wg-quick@warp failed with resolvconf: command not found and the regenerated profile had DNS = ... uncommented and no Table = off.

   I think I found why the protections get lost. It's the sed -i calls running on a symlink that ensure_warp_data_links then throws away.

   services/warp/utils.sh, generate_warp_wireguard_config():

   (cd "$svc_dir" && ./wgcf generate >/dev/null 2>&1)
   sed -i 's/\[Peer\]/Table = off\n\[Peer\]/g' "$svc_dir/wgcf-profile.conf"
   ...
   sed -i '/DNS = 1.1.1.1/s/^/# /' "$svc_dir/wgcf-profile.conf"
   mkdir -p /etc/wireguard/
   ensure_warp_data_links wireguard "$svc_dir"
   ln -sf "$svc_dir/wgcf-profile.conf" /etc/wireguard/warp.conf

   On an already-migrated install, $svc_dir/wgcf-profile.conf is a symlink to data/services/warp/wireguard/wgcf-profile.conf (created by an earlier ensure_warp_data_links). Step by step:

   1. wgcf generate writes through the symlink, so the data/ copy gets the fresh, unprotected profile.
   2. GNU sed -i doesn't follow symlinks by default. It writes its output to a new regular file at the link path. The symlink is replaced by a patched regular file, and the data/ copy stays unpatched. Quick check on the same box (GNU sed 4.8):

      $ echo orig > target; ln -s target link; sed -i s/orig/patched/ link
      $ cat target   -> orig
      $ cat link     -> patched   (link is now a regular file)
      

   3. ensure_warp_data_links sees that $svc_dir/wgcf-profile.conf is a regular file while the data/ copy already exists, so it takes the rm -f "$src" branch and re-links to data/. The patched file is deleted.
   4. /etc/wireguard/warp.conf -> $svc_dir/wgcf-profile.conf -> data/ copy = the profile without Table = off and with DNS =. That gives both failure modes described above: resolvconf missing, or wg-quick installing its policy routing for 0.0.0.0/0.

   Every apply goes through check_warp_wireguard_connection -> generate_warp_wireguard_config, so this comes back on every apply, not only once after the upgrade.

   Suggested fix (any of these):

   • sed -i --follow-symlinks ..., or
   • resolve the target first: local profile; profile="$(readlink -f "$svc_dir/wgcf-profile.conf")" and run all the seds on $profile, or
   • call ensure_warp_data_links right after wgcf generate and edit the data/ path directly.

   Manual workaround until then: on readlink -f /etc/wireguard/warp.conf, add Table = off before [Peer], comment out DNS =, then systemctl restart wg-quick@warp. Check with curl --interface warp https://www.cloudflare.com/cdn-cgi/trace (should show warp=on).