Cloudflare seems to not be responding

[tarasglek]

I used the app to register as documneted...after bringing up the interface cloudflare would barely function..something like 90% packet drop.

Seems that about 20% of my connection attempts are successful (eg wg-quick up).

Is this a common issue with them trying to snuff out unofficial clients or what is happening?

I don't have warp+, but I tried reusing key from mobile app, got:

WGCF_LICENSE_KEY="<mobile-key>" ./wgcf_1.0.5_linux_amd64 update
2020/04/19 21:27:44 Using config file: wgcf-account.toml
2020/04/19 21:27:45 Updated license key detected, re-binding device to new account
2020/04/19 21:27:46 non-200 status code
wgcf/cloudflare/util.doRequest
/drone/src/cloudflare/util/web.go:51
wgcf/cloudflare/util.NewAuthenticatedRequest
/drone/src/cloudflare/util/web.go:33
wgcf/cloudflare/api.UpdateLicenseKey
/drone/src/cloudflare/api/account.go:20
wgcf/cmd/update.updateLicenseKey
/drone/src/cmd/update/update.go:94
wgcf/cmd/update.ensureLicenseKeyUpdated
/drone/src/cmd/update/update.go:68
wgcf/cmd/update.updateAccount
/drone/src/cmd/update/update.go:52
wgcf/cmd/update.glob..func1
/drone/src/cmd/update/update.go:27
github.com/spf13/cobra.(*Command).execute
/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:846
github.com/spf13/cobra.(*Command).ExecuteC
/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:950
github.com/spf13/cobra.(*Command).Execute
/go/pkg/mod/github.com/spf13/cobra@v1.0.0/command.go:887
wgcf/cmd.Execute
/drone/src/cmd/root.go:36
main.main
/drone/src/main.go:10
runtime.main
/usr/local/go/src/runtime/proc.go:203
runtime.goexit
/usr/local/go/src/runtime/asm_amd64.s:1373
code: 400, body: {"result":null,"success":false,"errors":[{"code":1046,"message":"Invalid license"}],"messages":[]}

Is it possible to use the same key as on mobile?

[gr219]

Lots of license keys are shared publicly, I used to take one and tried to update by using this command and got that failure too. I guess there's nothing can be fixed here, it's from server's response

[ViRb3]

No, this is not normal. I have never experienced any packet drops or similar errors. I just tested wgcf update with a non-Warp+ account - works just fine here. Are you sure your license key is actually valid? Could you have reached the maximum 5 active linked devices limit? Could the key have been banned?

FYI, wg-quick up does not actually make any connection - the WireGuard protocol is state-less.

Anyway, I find it highly unlikely that this is a problem with the unofficial client. We'll need some more context on this:

• What country are you located in?
• Is there any firewall that could be interfering?
• Does Warp work without any issues through the mobile app?
• Are you trying to use the same WireGuard profile generated by this tool on 2 places at the same time? This will result in the server treating your devices as one device and will cause packet drops.

[syphyr]

I have noticed that there is a difference between running wg-quick on Android vs. Ubuntu 18.04. I am using the exact same source for the Wireguard kernel module on both systems, with the exact same Wireguard Cloudflare configs. Android functions 100% of the time and Ubuntu functions about 50% of the time. When Ubuntu has issues, "wg" shows the the connection is made, but there is no data getting transferred and I can not ping any outside addresses. But, I have to say that this issue only occurs with Cloudflare on Ubuntu. I have used other Wireguard vpns and they never have any issues with either Android or Ubuntu clients. So, the only difference I can see between Android and Ubuntu, in my situation, is that Android is using the official Wireguard App and Ubuntu is using wg-quick on the command line. It seems to be some kind of timing/race condition on Ubuntu with wg-quick, and only with Cloudflare vpn. My guess is the fix needs to be in wg-quick on Ubuntu.

[ViRb3]

The WireGuard protocol is stateless - there is no initial connection or handshare that happens. wg-quick up only brings up the interface and sets routing rules, as visible by the command log:

root@admin-pc:/etc/wireguard# wg-quick up wgcf-profile
[#] ip link add wgcf-profile type wireguard
[#] wg setconf wgcf-profile /dev/fd/63
[#] ip -4 address add REDACTED/32 dev wgcf-profile
[#] ip -6 address add REDACTED/128 dev wgcf-profile
[#] ip link set mtu 1420 up dev wgcf-profile
[#] resolvconf -a tun.wgcf-profile -m 0 -x
[#] wg set wgcf-profile fwmark 51820
[#] ip -6 route add ::/0 dev wgcf-profile table 51820
[#] ip -6 rule add not fwmark 51820 table 51820
[#] ip -6 rule add table main suppress_prefixlength 0
[#] ip6tables-restore -n
[#] ip -4 route add 0.0.0.0/0 dev wgcf-profile table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

I don't see how wg-quick could be at fault, other than the routing rules ending up not being correct. That being said, I have been using Cloudflare Warp through wg-quick extensively on Lubuntu 19.10 (based on Ubuntu), and I have never experienced any issues. Without more information and logs I am not sure how much I can help.

[ViRb3]

Closing due to lack of information. Feel free to follow-up and I will re-open.

[zadrakar]

I observed exactly the same behavior on Mint 19 and 20. In about 20% of cases, wgcf-profile does not work. I have no problem with other wireguard tunnels. Not on android with the same wgcf-profile. route-n, iptables, ip rule - everything looks the same in functional and non-functional state.

Workaround: script to restart wgcf-profile if warp does not work at the first time.