Unable to connect using debian 12 - Proxmox LXC

[gpz1100]

@ViRb3

Does the client in debian 12.5 (bookworm) still work with the .conf file generated using this tool?

Specifically, I can connected to warp (free acct) using the cf warp-cli tool. Using wg-quick, it connects but doesn't actually route. Ip route does not show route to cloudflare.

Same client/os will connect successfully to my vps running a wg server (also debian 12.5 based). Using same credentials and windows wireguard client, cf warp connection establishes successfully.

Any suggestions or thoughts would be welcomed. I'd like to get this working on the debian server.

[ViRb3]

I can confirm that it works fine for me on Debian 12, and I see no reason why the operating system would make a difference. Does a different device work? For example a phone using the official WireGuard app? Also, what country are you from? Regular WireGuard connections to Cloudflare are blocked in some countries with high abuse. In those cases, only warp-cli will work.

[gpz1100]

I'm in the US. I haven't tried android wireguard using warp creds, but windows with wireguard (not warp) client using wgcf creds works as well.

Tested the connection using pfsense (freebsd), where same creds as on the windows client work just fine.

Ubuntu was run as a vm under vmworkstation, debian as container and vm under proxmox.

[ViRb3]

If it's under Docker, you'll need to add the NET_ADMIN capability. Additionally, check for any errors like:

/usr/bin/wg-quick: line 31: resolvconf: command not found

You need to have resolvconf installed for DNS override. In either case, it should definitely work, and it's more than likely an issue with your setup.

[ViRb3]

For Docker, I also had to disable wg-quick's sysctl code since /proc is readonly:

sed -i 's/cmd sysctl/cmd true/g' "$(which wg-quick)"

And instead apply these changes directly via Docker's sysctl parameter:

net.ipv4.conf.all.src_valid_mark=1
net.ipv4.ip_forward=1

[gpz1100]

Thank you for your response. I was testing under proxmox (7.4) as a lxc container and vmworkstation (windows).

Earlier this afternoon I tried ubuntu bare metal on a spare machine. That worked, so that probably should work with debian too. That confirms the creds and client are good.

Further testing under proxmox lxc (debian 11) reveals strangeness. If I spawn the connection via local console it works! If I do the same via ssh, no traffic flows. Also there's the issue of proxmox breaking the symlink for /etc/resolv.conf.

Finally, because it's proxmox 7.4, the container needs to be spun up using debian 11 template. With deb 12, I couldn't get it to pass any traffic to the tunnel, even if trying to launch wg from the proxmox ui shell console. This suggests, cf wg configuration is somehow different than that of connecting to my vps, which I could do in either a debian 11 or 12 container and from ssh.

---

Edit 2, more tinkering with the debian 12 lxc container. If the cf wg tunnel is configured for autostart at boot with systemctl enable, then then tunnel does indeed successfully connect and has routing. In this scenario there is no ssh involved. If I drop the tunnel then try restarting via ssh, connectivity is lost and the container requires a reboot to re-establish routing. Even restarting the tunnel in the ui console isn't 100%, sometimes it works, other times not.

But via ssh, it never does recover. If I logout of the ssh session and do a wg restart in console, then it regains connectivity.

Edit3: I realize these issues have NOTHING to do with your tool which just obtains the credentials to use with the client.

[ViRb3]

There's a dedicated issue for various system configuration problems, maybe it helps: #50. Otherwise, yeah, I'm afraid I can't help much more, and this would be out of scope of wgcf. I hope you sort it out though!

[gpz1100]

I think the ultimate solution is to use a firewall with wireguard capability built in. Let it handle the connection and traffic routing rather than doing it on a vm/container level. Pfsense and Opnsense support this, probably others as well. This will eventually be implemented. For now, the solution above will have to do.