search

ViRb3 / wgcf

🚤 Cross-platform, unofficial CLI for Cloudflare Warp
MIT License
5.87k stars 664 forks source link

Internet access does not work (system issue) #50

Open naveenjohnsonv opened 3 years ago

naveenjohnsonv commented 3 years ago

Basically if I run wg-quick up wgcf-profile.conf I have no internet access, pings fail, but somehow telegram works. In the version without this revert commit , I had no internet at all, even in telegram. Only now when I updated to the version with this commit I find this irregularity. The same conf on other clients like android and windows work just fine. I'm on Pop!OS 20.10, which is based on Ubuntu 20.10 Any idea what could be the problem?

Edit from maintainer (09/11/2022):

Just to give some organization to all the "internet does not work" reports. There are two known cases when this may happen:

  1. If the WireGuard tunnel works on your other computer/phone, but not on this one, then it's likely an issue with your system configuration. It's generally not something I can help with, as wgcf is only responsible for providing you with a WireGuard profile, but leaving this issue open for people to share their experiences and solutions. This is tracked in #50.
  2. If the WireGuard tunnel does not work on any of your devices, but the official client does, then this is likely an issue with your region being restricted due to abuse prevention. There is no solution to this problem, maybe hope that people stop abusing the service so the regions are unlocked. Use the official client in this case. This is tracked in #158.

Edit from maintainer (26/11/2022):

Some more advise can be found here: https://github.com/ViRb3/wgcf/issues/50#issuecomment-1327944663

matroot commented 3 years ago

I was experiencing the same problem on ubuntu 20.04. I solved my problem by loading the wireguard module.

modprobe wireguard

I tried the same configuration on several systems like you and the problem only occurred on ubuntu.

felipejfc commented 3 years ago

no internet connection here either, already tried on both ubuntu and arch, by the time I connect I lose all internet connectivity. exactly same file works on windows though

matroot commented 3 years ago

no internet connection here either, already tried on both ubuntu and arch, by the time I connect I lose all internet connectivity. exactly same file works on windows though

try changing the MTU value to 1400.

felipejfc commented 3 years ago

it did work today! one issue I'm trying to debug is when I have wg connected to warp+ on a Linux machine on my lan, I want to use this linux machine as a gateway on my local lan so that all of my devices go through warp, however, when I do this, the connection speed on the lan machines is not as high as when I run on the device itself, I think maybe cloudflare is doing something to realise what I'm doing or either I'm messing something up :p and yes! I'm also brazillian :)

ViRb3 commented 3 years ago

This sounds like a network/ISP issue more than anything else. I am using wgcf extensively on Ubuntu 20.04 and I have no problems whatsoever. Unless somebody can propose a change or fix, I'm afraid I can't help much.

felipejfc commented 3 years ago

I've been able to use it for linux and it works fine. What I'm researching is, using this linux machine as a default gateway for other devices in the network, in this setup I don't get full download speeds for some reason...

ghost commented 3 years ago

I am using various versions of Fedora from 29 to 33. When I connect, only ipv6 works but no ipv4. When I try to disconnect and connect again for 100 times it finally starts working with no visible differences in routing and nft.

I mam located in Poland and I connect to 162.159.192.1:2408

Once it connects, it works without disconnecting for months.

ghost commented 3 years ago

I figured it out, it is not working if the network 160.0.0.0/5 is in Allowed IPs.

ghost commented 3 years ago

When I add 160 on systems where it was nearly impossible to connect, now they are connecting, sometims straight away, sometimes second time, depends on the machine. It's still not perfect so it cant be enabled at boot time, but it is somewhat usable in some way even without that one netqork.

naveenjohnsonv commented 3 years ago

When I add 160 on systems where it was nearly impossible to connect, now they are connecting, sometims straight away, sometimes second time, depends on the machine. It's still not perfect so it cant be enabled at boot time, but it is somewhat usable in some way even without that one netqork.

Only ipv6? For me I have the same issue, if I disconnect and connect within the first 5 tries it'll connect. Runs the command and then checks cloudflare trace to see if it's connected to warp if not I disconnect and reconnect again till it works

ishaqbhojani commented 3 years ago

Only ipv6? For me I have the same issue, if I disconnect and connect within the first 5 tries it'll connect. Runs the command and then checks cloudflare trace to see if it's connected to warp if not I disconnect and reconnect again till it works

@naveenjohnsonv @ViRb3 @thefalsedev @felipejfc @matroot I'm having same problem, did you guys find any solution? I'm using PopOS 20.10

LuuOW commented 3 years ago

Hey everyone, for all of those who's having trouble, i've found a solution, just change the endpoint in the conf file like this:

[Interface] PrivateKey = your_private_key Address = 172.16.0.2/32 Address = fd01:5ca1:ab1e:85e0:b48d:db14:f528:3a81/128 DNS = 1.1.1.1 MTU = 1280 [Peer] PublicKey = your_public_key AllowedIPs = 0.0.0.0/0 AllowedIPs = ::/0 Endpoint = engage.cloudflareclient.com:2408 <=============== THIS IS WHAT YOU HAVE TO CHANGE

just from "engage.cloudflareclient.com" DO NOT change the port, to other dns client, i've been using duckdns So now, my client looks like this:

[Interface] PrivateKey = your_private_key Address = 172.16.0.2/32 Address = fd01:5ca1:ab1e:85e0:b48d:db14:f528:3a81/128 DNS = 1.1.1.1 MTU = 1280 [Peer] PublicKey = your_public_key AllowedIPs = 0.0.0.0/0 AllowedIPs = ::/0 Endpoint = place_your_dns_here:2408 <====== this is what it changes, not the port, again

These are the ips of engage.cloudflareclient.com, so your dns must refer to this ips:

Lookup IPv4 Address: 162.159.192.1 Lookup IPv6 Address: 2606:4700:d0::a29f:c001

I hope you can solve your problems.

berkant commented 3 years ago

I have been having these same problems since the very early bash scripts to use Warp on Linux. wg-quick up either connects me to Cloudflare, or drops all connectivity.

Wondertan commented 3 years ago

Having the same issue. After wg-quick up wgcf-profile.conf all the Internet connectivity drops except for Telegram. However, from time to time, I can still flawlessly use WARP, though I did not catch the working state pattern.

I am using Arch btw ;)

fuccsoc commented 3 years ago

I'm ashamed to admit, but I solved this problem by randomly changing the MTU value after each connection.

gothmog123 commented 3 years ago

hi i'm also facing the no internet issue. any other tips on how to troubleshoot it?

berkant commented 3 years ago

@gothmog123 I know none other than bruteforcing wg-quick up and wg-quick down until you get connectivity. I have even tried boringtun[1] (Cloudflare's own userspace WG implementation which they also use in Warp) yet to no avail. It stalls with that too.

[1] https://github.com/cloudflare/boringtun

Wondertan commented 3 years ago

@gothmog123, @0xbkt, I end up with this small script: systemctl restart wg-quick@wgcf-profile && curl -m 1 ifconfig.me

  1. Restarts wgcf
  2. Checks that my IP is behind Cloudflare

So I rerun this until I get success and that works for me always

hambergerpls commented 3 years ago

@gothmog123, @0xbkt, I end up with this small script: systemctl restart wg-quick@wgcf-profile && curl -m 1 ifconfig.me

  1. Restarts wgcf
  2. Checks that my IP is behind Cloudflare

So I rerun this until I get success and that works for me always

I tried this, and it works on my Pop!OS 20.10. This is so weird that we have to brute force until it works.

yura-pakhuchiy commented 3 years ago

I have a similar issue in Ubuntu 18.04. After connecting with wg-quick only IPv6 works, but IPv4 does not. Commenting out IPv4 address helps. My config looks like this:

[Interface]
PrivateKey = xxx
#Address = 172.16.0.2/32
Address = fd01:5ca1:ab1e:xxx/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = xxx
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = 162.159.192.1:2408

Note only IPv4 should be commented. If I comment IPv6 address then IPv6 stops working. I've also changed Endpoint to IP address, but it does not seem to make a lot of difference.

Wondertan commented 3 years ago

@yura-pakhuchiy, this works for me actually. I will report how it goes over time. Thanks.

yura-pakhuchiy commented 3 years ago

@ViRb3 My guess is that Cloudflare provides different local address to a client on each connection. When it matches with 172.16.0.2, then it works, otherwise user have to reconnect. It might be static 172.16.0.2 in some locations (then it will work every time) and dynamic in others. Datacenter I use is in Warsaw, Poland. Omitting IP address probably allows Wireguard to figure it out automagicly in Linux. Problem is that Keenetic router forces you to enter IP address, so omitting address is not solution for everyone.

Just a guess. I have not really debugged the issue.

ViRb3 commented 3 years ago

@yura-pakhuchiy wgcf doesn't use a static IP address, it uses the one that Cloudflare sends it:

https://github.com/ViRb3/wgcf/blob/1780811d56b3f2165b32158ac8443c6820bf0fe4/cmd/generate/generate.go#L49-L55

As far as I'm aware you cannot omit all Address fields in WireGuard. By commenting out one of them, you are forcing it to use the other one. In the above case, you're forcing it to use IPv6. I would love to help diagnose this issue but I can't reproduce it - I have never experienced a single problem with wgcf, and I have been using it 24/7 for months.

Wondertan commented 2 years ago

The solution with commenting ouy IPv4 address has stopped working for me, unfortunately. Now I need to restart wg-quick multiple times to get it working again.

m-sahebi commented 2 years ago

i have same issue, changing MTU to 1400 makes telegram app connect but nothing more. commenting out ipV4 address in the config file was the solution for me. wgcf 2.2.10 amd64 Ubuntu 20.04

galpt commented 2 years ago

I'd say this isn't a bug as there's not much changes to make with the wgcf. I did test and have some old data that in 2020, Cloudflare used 1280 as their warp server mtu. But the new mtu (used until now) is 1360.

I suggest @ViRb3 you can update the README.md and the code a little to autoset the mtu to 1360. I've been working with cloud servers for 3+ years and for most cases with VPNs, if user's mtu isn't the same as the server mtu, this can results in connection problems, starting from users don't get the full speed benefit or getting as worse as can't connect to apps.

1360 is the official mtu on Windows, but it should be the default on Linux or Android too. You can try it manually maybe based on my settings here

[Interface]
PrivateKey = ${{ PRIVATEKEY }}
Address = 172.16.0.2/32, fd01:5ca1:ab1e:8516:e91f:aaa7:f7da:87a6/128
DNS = 1.1.1.1
MTU = 1360

[Peer]
PublicKey = ${{ PUBLICKEY }}
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = ${{ ENDPOINT }}
PersistentKeepalive = 5
ViRb3 commented 2 years ago

@galpt could you please confirm that the MTU is the same across all major platforms, namely Windows, Linux, Android, and iOS? When I created wgcf, I took the MTU from what was default for Android at the time, so 1280. I do not have any test devices with me at the moment, but I am happy to change the MTU if it's really 1360 for all platforms. Otherwise, this is likely not the root cause of the issue.

I am going to double-check @yura-pakhuchiy's theory though, because while I am using the local address that Cloudflare provides us, I only do this once when the profile is generated, while in reality it may be changing before each connection.

⚠️ For anyone experiencing the "no internet connection" issue, could you please re-generate THE SAME account using wgcf generate, and see if it works? If it does, are the Address properties of your old and new WireGuard profiles different?

yura-pakhuchiy commented 2 years ago

I think my theory was wrong. I've checked with Wireshark what actually happens when we don't specify IPv4 in config. If we do specify IP, then it is assigned to tunnel interface and used for all outgoing packets as source IP. If there is no IP specified in config, then it uses your IP in your local network (wifi, eth, whatever) as source IP. It is kinda random IPs but they do work, but the specific ones from config - do not. Looks like bug in wireguard itself, not some configuration problem.

galpt commented 2 years ago

@ViRb3 for Windows, we can connect to the official warp client first and then open cmd as admin then use this command netsh interface ipv4 show subinterface using official 1.1.1.1 warp client. On Linux you can use the official warp client and try to ifconfig or use bmon to see if there's any changes to your mtu after connecting to official warp.

About the Address part, I just followed the default addresses used by the official warp for Android. It's an old data, and it's not easy to get your hands to it cuz you'll at least need a rooted Android, maybe bluestacks or other rooted emu, going to the warp client dir and we can find a file that contains all the user registration info from ID to license key. The problem is I don't have bluestacks setup right now, haven't used it again since last 2020.

The easiest way to confirm if it will fix everyone's problems is to just change the mtu to 1360 and try to test it directly using wireguard client. Pretty sure warp Address and Endpoint won't be changed by Cloudflare as changing either one of them is like changing your WiFi name, everyone will be having a hard time connecting to warp. Unless they have fatal issue that requires them to change the Address and Endpoint.

ghost commented 2 years ago

I am in Poland and I was unable to use wgcf any more now for 2 months. Only official client worked. I tried very hard. The IP ranges changed also with the new client. Now I tried wgcf and it works on the first shot. And also is using the new range.

My config:

[Interface] PrivateKey = XXXX Address = 172.16.0.2/32 Address = fd01:5ca1:ab1e:8648:2f47:XXX

DNS = 1.1.1.1

MTU = 1432 [Peer] PublicKey = XXX AllowedIPs = 0.0.0.0/0 AllowedIPs = ::/0 Endpoint = 162.159.192.4:2408

The endpoint I got from the official client, but the default one from wgcf also works.

My native MTU is 1492 (pppoe).

galpt commented 2 years ago

@thefalsedev even tho your router mtu is set to 1492, pretty sure your OS is playing a role of using the default 1500 when disconnected from warp. You can use official 1.1.1.1 client for your OS and check whether your mtu changes or not after connected to warp.

But either 1500 or 1492 is a little too far from 1280, so at least we can suspect this temporarily. As for the 1360, that's what I got from using the official client on Windows.

ghost commented 2 years ago

My MTU on router is 1492. This minus wireguard overhead of 60 bytes for tunnel over ipv4 it gives 1432 maximum MTU I can use and I dont mind privacy issues with this, I am mainly avoiding going thru router of my isp which has ssh port open and it's not updated for 8 years. I am using dns on 127.0.0.1 which is unbound connected to 1.1.1.1 via Dns Over TLS (so it also works when not connected to warp).

ghost commented 2 years ago

My latest warp-cli connect gives this interface, so it's MTU 1280 at the moment.

CloudflareWARP: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1280 inet 172.16.0.2 netmask 255.255.255.255 destination 172.16.0.2 inet6 XXX prefixlen 64 scopeid 0x20 inet6 XXX prefixlen 128 scopeid 0x0 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 16 bytes 6459 (6.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 33 bytes 4108 (4.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

galpt commented 2 years ago

My latest warp-cli connect gives this interface, so it's MTU 1280 at the moment.

CloudflareWARP: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST> mtu 1280 inet 172.16.0.2 netmask 255.255.255.255 destination 172.16.0.2 inet6 XXX prefixlen 64 scopeid 0x20 inet6 XXX prefixlen 128 scopeid 0x0 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 500 (UNSPEC) RX packets 16 bytes 6459 (6.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 33 bytes 4108 (4.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

@thefalsedev did you get that mtu without changing anything? if yes then that's the official mtu for Linux. I don't have Linux to test official warp directly right now, only some vps but as you know vps can't use warp/other vpn as that will change the vps IP and make it unusable. for now official warp client for Windows will create a new network interface and use 1360 as the mtu. pretty sure mtu isn't supposed to be different from cloudflare's server as that will affect connectivity to either user/server.

ghost commented 2 years ago

I got that without changing anything in warp-cli. Because MTU can be deducted by website from the packet, it is privacy risk. Therefore all clients should have the same MTU. So it needs to be something which will work for everyone. 1280 is minimum MTU for ipv6 and it should work with all mobile and landline internet with all sorts of encapsulations. But the performance suffers, so they increased it to 1360 and that should also work with all sorts of encapsulation for mobile networks. However on cloudflare end it should accept 1500-60, or even 9000-60 possibly if you have such route. So for privacy reasons it's good to use what everyone uses, but if you want performance you can increase it to your maximum, by determining what is you MTU (it's not what on the interface, but the minimum on all your hops), substracting 60 from it and that's it.

galpt commented 2 years ago

@thefalsedev if I were you, I will just use official warp client and let the app decide what mtu value to use, cuz that's what cloudflare has set for everyone officially and they know best about their networks.

experimenting is just optional and that's not recommended for everyone especially if they have no background whatsoever in networking stuff.

if folks are using wgcf then I guess they need to test what settings work best for them. but for starters, using official client and leave everything as default is recommended.

hmm.. pretty sure not everyone supports jumbo frame. eventho your OS supports it, everything has to go through your router first, and chances are most ISP routers aren't that advanced. unless your PC/laptop can connect directly to the fiber cable, most desktops only have LAN port built-in, and 1500 is the standardised value so that should works for most devices.

tl;dr — I'll stay with the defaults. guess everyone needs to experiment further to find the real issue here.

shirakun commented 2 years ago

Hi I have the same problem But this issue seems to be an OS issue, not a wgcf/warp/wireguard issue I am using warp in Ubuntu/Debian/Alpine Linux This problem always occurs on OpenVZ/lxc virtualized alpine linux I try to use wireguard-go and boringtun as client ipv4 doesn't work (without any routing) when connecting to warp with ipv6 while everything works fine with ipv6 Try to run register again, the same problem when copying available files from other OS to alpine linux

And when using ipv4 to connect to the warp, both ipv4 and ipv6 work normally

In addition to this, I also tried adding a rule like the following in sysctl, but nothing seems to work

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
galpt commented 2 years ago

@shirakun It seems this isn't just limited to Linux but my wgcf on Windows doesn't seem to connect at all eventho the config is up-to-date with warp+ license key. I wonder if Cloudflare did change something on their backends that are related to warp. Since it happens on Windows too, that means it has nothing to do with your sysctl.conf.

shirakun commented 2 years ago

Hi I have the same problem But this issue seems to be an OS issue, not a wgcf/warp/wireguard issue I am using warp in Ubuntu/Debian/Alpine Linux This problem always occurs on OpenVZ/lxc virtualized alpine linux I try to use wireguard-go and boringtun as client ipv4 doesn't work (without any routing) when connecting to warp with ipv6 while everything works fine with ipv6 Try to run register again, the same problem when copying available files from other OS to alpine linux

And when using ipv4 to connect to the warp, both ipv4 and ipv6 work normally

In addition to this, I also tried adding a rule like the following in sysctl, but nothing seems to work

net.ipv4.ip_forward = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

By modifying the mtu you can probabilistically make it work At the moment I don't have any way to find the exact mtu that can make ipv4 work

Pick a random mtu from 1420~1280 Then try to connect, and if it doesn't work properly with ipv4, replace it with another mtu.

The same mtu will still face the problem that ipv4 does not work when it is connected for the second time (after reconnecting to warp, ipv4 not working again.). In this case, you need to modify the mtu and try to connect again.

Modifying the mtu also affects the connection to part of the ipv6 (part of the subnet is not routed, but it is not clear how the mtu is related to this part of the subnet)

In addition, there may be a situation where ipv4 is available immediately after connection, but after some time ipv4 is not routed I tried to add PersistentKeepalive = 25 to the configuration file for this problem, and the problem did not occur again after adding it

RealEthanPlayzDev commented 2 years ago

Hi, I just installed wgcf from AUR (wgcf-git) and I'm having this issue, internet connectivity is gone each time I start the wg-quick@wgcf-profile systemd service, I've tried changing Endpoint to the ip, changing MTU but they don't seem to work, however using the following command from @Wondertan works, is there a way to put this to an systemd service that autostarts?

systemctl restart wg-quick@wgcf-profile && curl -m 1 ifconfig.me

  1. Restarts wgcf
  2. Checks that my IP is behind Cloudflare

So I rerun this until I get success and that works for me always

Kernel: 5.16.4-242-tkg-cfs (using custom kernel: https://github.com/Frogging-Family/linux-tkg) Network service: NetworkManager

And no, I do not want to use the official warp-cli because I need to get hacky for the connection to stay, this once bricked internet connectivity and caused a headache for me

EDIT: I noticed that only my IPv6 got connected to WARP, but not IPv4?

Handsome1080P commented 2 years ago

No network, no receiving data.MTU already set to 1200.My phone app no network too.I am living in USA.But using Official WAR-Cli it's working.So just using Official one.This one is out of date.

juev commented 2 years ago

Hello,

I was try to generate new account with profile on MacOS Monterey 12.3.1 (21E258). Then I was try to use my Warp+ Unlimited account. Result the same.

Profile:

[Interface]
PrivateKey = xxx
Address = 172.16.0.2/32
Address = fd01:5ca1:ab1e:85d7:8c00:e9ef:f7c6:aa48/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = xxx
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:2408

Ping:

$ ping 162.159.192.1
PING 162.159.192.1 (162.159.192.1): 56 data bytes
64 bytes from 162.159.192.1: icmp_seq=0 ttl=54 time=55.641 ms
64 bytes from 162.159.192.1: icmp_seq=1 ttl=54 time=53.977 ms
64 bytes from 162.159.192.1: icmp_seq=2 ttl=54 time=56.857 ms
^C
--- 162.159.192.1 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 53.977/55.492/56.857/1.180 ms

# after connect
$ ping 162.159.192.1
PING 162.159.192.1 (162.159.192.1): 56 data bytes
Request timeout for icmp_seq 0
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C
--- 162.159.192.1 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

I was try to change MTU, Endpoint. But after connecting network is not work.

oxwivi commented 2 years ago

I've had the exact issue since day one of using wgcfon Linux. It absolutely baffles me how a configuration file that works perfectly fine on both Android and Windows' (even with the kernel driver since its experimental phase) official WireGuard clients somehow fail to work with Linux.

As per my research, I found that disabling systemd-resolved and letting NetworkManager use dnsmasq instead will almost certainly establish a perfectly functional connection. Which I absolutely do not like because I'd rather use resolved's DoT and DNSSEC functions, but no matter what I do, I can't get wgcf and resolved to play nice. And whenever it does work, most of the time it's IPv6 only, as others have reported here.

I also suspected it's a Linux-specific issue, not a wgcf one, but I got conf file from a friend who has setup his own WG server and it works perfectly fine with systemd-resolved. The only differences with my friend's conf file is, no IPv6 configured, uses PSK and endpoint is an IPv4 address, not a domain. I don't know if any of those has anything to do with resolved, but none of the other solutions here (modprobe, MTU, IP address of endpoint) has helped me.

TL;DR Make sure you've dnsmasq installed and diisable systemd-resolved, delete/backup /etc/hosts, restart NetworkManager, connect to wgcf-profile, ???, profit

oxwivi commented 2 years ago

I have some new observation on the systemd-resolved issue. I've noticed if you remove /etc/resolv.conf (by default configured for resolved's stub resolver, I believe), NetworkManager recreates it and resolved operates in resolv.conf mode: foreign. With this setup, I can have both systemd-resolved's DNS over TLS and DNSSEC, and wgcf connection no longer breaks. I don't know what the default resolv.conf does that breaks wgcf VPNs, but that's an investigation for another day.

cwegener commented 2 years ago

I have a similar issue in Ubuntu 18.04. After connecting with wg-quick only IPv6 works, but IPv4 does not. Commenting out IPv4 address helps. My config looks like this:

[Interface]
PrivateKey = xxx
#Address = 172.16.0.2/32
Address = fd01:5ca1:ab1e:xxx/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = xxx
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = 162.159.192.1:2408

Note only IPv4 should be commented. If I comment IPv6 address then IPv6 stops working. I've also changed Endpoint to IP address, but it does not seem to make a lot of difference.

That's the solution for me. Thanks so much!

andruska commented 1 year ago

Can confirm - commenting out IPv4 row gets Cloudflare Warp back.

I experienced similar problems two months ago with Android (using wgcf generated profile with Wireguard app) and now with Archlinux. Under Android, the problem somehow resolved itself within a few weeks. But now, when it happened also in Linux, I started investigation and happened to reach here.

The symptoms of the Internet access problems were both similar under Android and Linux. The only services that worked properly then, were DNS inquiries to NextDNS (NextDNS global entires in systemd resolved.conf, DNS row in wgcf profile is commented out), Google search in browser and Gmail smtp/imap. All other sites and services were unreachable.

therysin commented 1 year ago

Happens on windows for me too :(

Seems to work on linux, no clue whats going on.

image

shirakun commented 1 year ago

Happens on windows for me too :(

Seems to work on linux, no clue whats going on.

image

https://github.com/ViRb3/wgcf/issues/158#issuecomment-1058377722 should be the cause of this, but it is not clear how reserved is calculated, so can not solve the problem.

ViRb3 commented 1 year ago

Just to give some organization to all the "internet does not work" reports. There are two known cases when this may happen:

  1. If the WireGuard tunnel works on your other computer/phone, but not on this one, then it's likely an issue with your system configuration. It's generally not something I can help with, as wgcf is only responsible for providing you with a WireGuard profile, but leaving this issue open for people to share their experiences and solutions. This is tracked in #50.
  2. If the WireGuard tunnel does not work on any of your devices, but the official client does, then this is likely an issue with your region being restricted due to abuse prevention. There is no solution to this problem, maybe hope that people stop abusing the service so the regions are unlocked. Use the official client in this case. This is tracked in #158.
extratype commented 1 year ago

You can see your endpoint addresses in C:\ProgramData\Cloudflare\cfwarp_service_log.txtfor the official Windows client. Find Endpoints: [WarpSocketAddrPair {. Endpoints for an unlimited license are different from ones for a free license. I tried the first one for Endpoint in my WireGuard profile and it worked. The official client changes the MTU as well, so I added it to my profile: MTU = 1360.

wgcf_2.2.12_windows_amd64.exe generate did not change the Endpoint after update with my unlimited license. It was fixed to engage.cloudflareclient.com:2408.