search

ViRb3 / wgcf

🚤 Cross-platform, unofficial CLI for Cloudflare Warp
MIT License
6.04k stars 679 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

nwpr commented 1 year ago

Hey! I did some research on Cloudflare's infrastructure and possible causes for problems. Here are some tips that might help you.

Hope this helps to solve some of your problems.

shirooo39 commented 1 year ago

I'm not sure what's going on but this is driving me extremely mad!

I don't think this is an issue caused by wgcf, more ofa wireguard issue because the Android client hasn't heen updated in ages! and I really need help with this one.

it's a gacha when I tap on the connect toggle. I even tried it more than 10x but not connecting a single time. the moment it connects, that's when I got so lucky. I tried the exact same wg profile on wireguard Windows and it worked with no issue at all! connects instantly.

I'm on the latest crDroid 9.2 running on top of Android 13. my kernel does support WG Kernel mode but the WG app doesn't seem able to use it, so I'm running in the userspace. I also don't think because I'm on a custom rom, because on basically every custom rom I've ever tried, the issue is still there. even the official 1.1.1.1 Android client is extremely trash that the same issue is also present.

https://user-images.githubusercontent.com/38461122/219287004-330a836f-9d65-4794-ba7e-1bcd7088a623.mp4

shirakun commented 1 year ago

I'm not sure what's going on but this is driving me extremely mad!

I don't think this is an issue caused by wgcf, more ofa wireguard issue because the Android client hasn't heen updated in ages! and I really need help with this one.

it's a gacha when I tap on the connect toggle. I even tried it more than 10x but not connecting a single time. the moment it connects, that's when I got so lucky. I tried the exact same wg profile on wireguard Windows and it worked with no issue at all! connects instantly.

I'm on the latest crDroid 9.2 running on top of Android 13. my kernel does support WG Kernel mode but the WG app doesn't seem able to use it, so I'm running in the userspace. I also don't think because I'm on a custom rom, because on basically every custom rom I've ever tried, the issue is still there. even the official 1.1.1.1 Android client is extremely trash that the same issue is also present.

No community member has the responsibility to keep you from getting angry So, you can choose to remain angry Your anger may put some community members in a happy mood

QFq1UEWj

sgloutnikov commented 1 year ago

@shirooo39 I am running into the same non-deterministic behavior on Android with an Nvidia Shield (v9.1.1) as well. Feels completely random when it actually works. Just now, updated to the latest Android TV WireGuard client: 1.0.20230321.

I have been trying different combinations of steps and while the following may be unrelated or random magic, I'm able to get a successful internet connection consistently at the moment:

  1. Generate your regular profile with wgcf and make a copy of it: Calling my files local.conf and local2.conf
  2. Load them both into the WireGuard Android client.
  3. Select and activate one: local. Here usually my rx is very low, a few hundred bytes, thus no internet connection.
  4. While local is still activated, select local2. If your rx goes into kilobytes you most likely have a successful internet connection.
  5. If rx is still low, while local2 is still activated go and activate local again.

After 1 or 2 switches between the two, with the other still activated, my connection starts to work and I have no idea why.

Here is my config, with the 192.168.0.0/16 network excluded:

[Interface]
PrivateKey = <PRIVATE_KEY>
Address = 172.16.0.2/32
Address = <IPV6_ADDRESS>/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = <PUBLIC_KEY>
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3, ::/0
Endpoint = engage.cloudflareclient.com:2408
shirooo39 commented 1 year ago

@shirooo39 I am running into the same non-deterministic behavior on Android with an Nvidia Shield (v9.1.1) as well. Feels completely random when it actually works. Just now, updated to the latest Android TV WireGuard client: 1.0.20230321.

I have been trying different combinations of steps and while the following may be unrelated or random magic, I'm able to get a successful internet connection consistently at the moment:

1. Generate your regular profile with `wgcf` and make a copy of it: Calling my files `local.conf` and `local2.conf`

2. Load them both into the WireGuard Android client.

3. Select and activate one: `local`. Here usually my `rx` is very low, a few hundred bytes, thus no internet connection.

4. While `local` is still activated, select `local2`. If your `rx` goes into kilobytes you most likely have a successful internet connection.

5. If `rx` is still low, while `local2` is still activated go and activate `local` again.

After 1 or 2 switches between the two, with the other still activated, my connection starts to work and I have no idea why.

Here is my config, with the 192.168.0.0/16 network excluded:

[Interface]
PrivateKey = <PRIVATE_KEY>
Address = 172.16.0.2/32
Address = <IPV6_ADDRESS>/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = <PUBLIC_KEY>
AllowedIPs = 0.0.0.0/1, 128.0.0.0/2, 192.0.0.0/9, 192.128.0.0/11, 192.160.0.0/13, 192.169.0.0/16, 192.170.0.0/15, 192.172.0.0/14, 192.176.0.0/12, 192.192.0.0/10, 193.0.0.0/8, 194.0.0.0/7, 196.0.0.0/6, 200.0.0.0/5, 208.0.0.0/4, 224.0.0.0/3, ::/0
Endpoint = engage.cloudflareclient.com:2408

yup, if rx is low = no internet
I don't get why turning it on/off a bunch of times rapidly still won't fix the issue but your method sounds like it'll work

but again, the issue is within the wireguard app itself, it's so damn ancient and hasn't been updated for years.
they just straight out abandoned the project.

on windows tho, it connects normally. quick and no issue.

road2react commented 1 year ago

I have multiple devices on the same network. The first device connects properly. The second device connects and completes the handshake, and is able to access the internet, but very slowly.

Anyone know how to fix this?

galpt commented 1 year ago

@sgloutnikov @shirooo39 Check whether your router/ISP is using IPv6 or not. Removing the IPv6 from the [Interface] and [Peer] might tell the WG client to only use IPv4. Any servers usually support IPv4 out-of-the-box, but not IPv6. Also you could try changing the DNS to your router gateway IP first (e.g. 192.168.1.1) and see if you could connect with that. It might be something preventing us to resolve DNS properly, as we all know anything on the Internet starts with a DNS name resolution, including VPN.

@road2react That's a sign that you're using 1 config for multiple devices, and WG only supports 1 config for 1 device. The official Warp client also does this by registering a new profile and creating a new config for each device. To fix this, do wgcf register & wgcf generate for every new device. Here is the more technical answer.

guyru commented 10 months ago

My issue that IPv6 networking works well, but IPv4 doesn't.

[Interface]
PrivateKey = XXXXXXXXXXXXX
Address = 172.16.0.2/32
Address = 2606:4700:110:8bdc:63bb:bde6:efce:ddc1/128
MTU = 1280
[Peer]
PublicKey = XXXXXXXXXXXXXXXXX
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = engage.cloudflareclient.com:2408

Things I've tried without success.

I use a similar configuration to connect to another WireGuard instance on my private VPS, and it has no problems with IPv4 connections.

Any help would be appreciated.

Sepero commented 10 months ago

Here's a Linux loop that will keep trying until you get connected. It can be run as a single line

while ! ping -w1 -c1 1.1.1.1; do wg-quick down wgcf-profile; wg-quick up wgcf-profile; done

I also found that changing the MTU in wgcf-profile.conf helped get me connected. It seems I could change the MTU to almost anything

dhiyaulhaqZA commented 10 months ago

I resolve this issue by :

  1. Commenting out IPv4 address
  2. Change Endpoint port to 500
  3. Add PersistentKeepalive = 28
  4. Add 1.1.1.1 & 8.8.8.8 name server to /etc/resolv.conf

wgcf-profile.conf

[Interface]
PrivateKey = mMTyrI+vpYSkb1BWg3E/az400QDoYNaOC/CkUhQX22Y=
#Address = 172.16.0.2/32 # <-- comment this
Address = 2606:4700:110:8e7a:480d:f434:be51:45b6/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:500 # <-- change port to 500
PersistentKeepalive = 28 # <-- add this

/etc/resolv.conf

# Generated by resolvconf
nameserver 1.1.1.1
nameserver 8.8.8.8
Sepero commented 10 months ago

@dhiyaulhaqZA That's far more steps than I use to get a connection. Questions. Have you tried removing any of those parts and still having success? Are you able to connect nearly 100% of the time with your setup?

galpt commented 10 months ago

@dhiyaulhaqZA That's far more steps than I use to get a connection. Questions. Have you tried removing any of those parts and still having success? Are you able to connect nearly 100% of the time with your setup?

Probably /etc/resolv.conf was the problem. Newer Ubuntu releases use systemd-resolved and this could affect how apps connect to the Internet from your machine. Before successfully establishing a new VPN connection, your machine will make some DNS requests to the VPN server.

  1. Misconfigured/unconfigured DNS settings could result in people failing to connect to Warp servers. I think this theory is reasonable enough, people tend to forget the most basic things. DNS is probably the 1st thing everyone wants to check, since everything starts with a DNS request. Of course, this is only true if there's no other cause that's preventing people from connecting to Warp (e.g. firewall, etc.).

  2. If everyone has noticed, the IPv4 will be the same for new generated configs, only IPv6 will be unique. This is also how the original WireGuard works too (1 IP = 1 device-config). When 2 people got the exact same IP address, then they will compete for eachother to connect to the WireGuard server - or the correct word might be "your router might be confused of which device it has to send the VPN traffic to". It might confuse the Warp servers too. In networking, 1 IP = 1 Device, so not just for WireGuard. So messing with the IP won't really solve anything, since chances are quite rare for that to happen, to the point that IP might not be the problem in the first place.

aloptrbl commented 10 months ago

I resolve this issue by :

  1. Commenting out IPv4 address
  2. Change Endpoint port to 500
  3. Add PersistentKeepalive = 28
  4. Add 1.1.1.1 & 8.8.8.8 name server to /etc/resolv.conf

wgcf-profile.conf

[Interface]
PrivateKey = mMTyrI+vpYSkb1BWg3E/az400QDoYNaOC/CkUhQX22Y=
#Address = 172.16.0.2/32 # <-- comment this
Address = 2606:4700:110:8e7a:480d:f434:be51:45b6/128
DNS = 1.1.1.1
MTU = 1280
[Peer]
PublicKey = bmXOC+F1FxEMF9dyiK2H5/1SUtzH0JuVo51h2wPfgyo=
AllowedIPs = 0.0.0.0/0
AllowedIPs = ::/0
Endpoint = engage.cloudflareclient.com:500 # <-- change port to 500
PersistentKeepalive = 28 # <-- add this

/etc/resolv.conf

# Generated by resolvconf
nameserver 1.1.1.1
nameserver 8.8.8.8

i test this on windows 11 using wireguard but not working. look like the handshake failed test

galpt commented 10 months ago

@aloptrbl Have you tried using other ports? Refer to the official docs:

Also check their status page to make sure there's nothing affecting Warp-related services. https://www.cloudflarestatus.com/

nazdridoy commented 9 months ago

I resolve this issue by :

  1. cp ./wgcf-profile.conf /etc/wireguard/
  2. import wgcf-profile.conf with KDE network manager
  3. connect wgcf-profile using networkmanager-gui
  4. wg-quick down wgcf-profile

For some weird reason, this works for me every time. Commenting out both 'Address' lines also works."

aloptrbl commented 9 months ago

@aloptrbl Have you tried using other ports? Refer to the official docs:

Also check their status page to make sure there's nothing affecting Warp-related services. https://www.cloudflarestatus.com/

have tried all this port: engage.cloudflareclient.com: 2408, 500, 1701, 4500

no handshake or transfered data being received.

galpt commented 9 months ago

@aloptrbl Maybe try using different network, such as cellular data? Some wifi (or routers to be more specific) might not allow VPN connections. I was using Warp (free & plus) until this morning from my smart tv, no issue at all. So doesn't seem like an issue from cf.

guyru commented 9 months ago

Here's a Linux loop that will keep trying until you get connected. It can be run as a single line

while ! ping -w1 -c1 1.1.1.1; do wg-quick down wgcf-profile; wg-quick up wgcf-profile; done

I also found that changing the MTU in wgcf-profile.conf helped get me connected. It seems I could change the MTU to almost anything

This worked, and after several retries I'm now getting a working connection quite consistently. But why did re-attempting work?

oxwivi commented 9 months ago

I finally figured out how to connect to the service reliably: disable my local IPv6 connection. No matter how many times I disconnect and reconnect, WG always successfully reconnects. The reason I had spotty connection issues were because my IPv6 connection was broken, so I speculate my looping connect/disconnect was mostly attempted over v6 and successfully connected over v4. And I figured it out because my IPv6 got completely fixed today, and I wasn't able to connect at all—until I disabled v6 on NetworkManager. I also see on the logs that my Windows device resolves engage.cloudflareclient.com and connects to the v4 address (very anecdotal observation, however, it always worked reliably so I didn't pay the logs mind).

The problem is, I do want to use IPv6.

Is this the same for anyone else? And have you figured out how to connect to WARP over IPv6?

PS Long, long ago, I do remember once having only the v4 address in my conf file as suggested here instead of engage.cloudflareclient.com and it didn't work for me. No idea why that might be the case.

oxwivi commented 9 months ago

Follow up to my last comment: confirmed on Windows machine if I disable IPv4, 2408 doesn't work, even if I can ping and resolve proper IPv6 address of engage.cloudflareclient.com; port 500 appears to work fine, however. AFAICT, multiple endpoint addresses can't be define, so I added three more peers with all the ports as linked above:

Refer to the official docs:

With this—at least at my current location and ISP—I've no more complaints with either the WARP service or the wgcf tool. I sincerely thank ViRb3 for this amazing little thing. My last comment on it would be to maybe add all the ports to the generated conf file. Oh, and the Exclude Private IPs thing that WireGuard's Android client does would be very useful as an option for wgcf.

oxwivi commented 9 months ago

Never mind, my joy was short-lived. I don't what's at fault here, maybe Linux or maybe NetworkManager handles WireGaurd ass-backwards, but neither the port 500 trick, nor the multiple peers are working on my main Fedora machine with IPv6 enabled. My disappointment is immeasurable, and my day ruined.

oxwivi commented 9 months ago

I've successfully got to connect to WARP with IPv6 enabled. For context of the following, I'm using NetworkManager, on Fedora 39; I didn't install wg tool bundle, so I've no comparison that, I'll can detail cause and effect with this setup and compare to my Windows experience.

First the main blocker: a firewalld bug. IPv6_rpfilter is enabled by default, but it blocked WG over IPv6. This is not the intended behavior as indicated in the issue, but disabling it is the easiest workaround. Not sure how the IPv6 experience would be, but if your machine is getting IPv6 GUA/global address, by default WireGaurd will attempt IPv6 connection and silently fail if your v6 connection is not up to the task as mine was until last week.

Second blocker, not sure if NetwrokManager specific or not: connection fails if IPv6 DNS is not defined. This is only the case for WG over IPv6; if v6 is disabled WG over v4 works fine even if v6 DNS is not defined. On Windows, WG over v6 is working fine without any v6 DNS, so I'm half-convinced it's a NM quirk. wgcf adding v6 DNS the conf file would be nice.

With the above workarounds, WG over both v4 and v6 should be working fine without having to cycle connect/reconnects. At least that is the case for me this far. That said, WG over v6 still isn't the smoothest experience however. Without MTU defined on NetworkManager, sites mostly work, quite a few don't. But even with default 1280 some sites like Proton Mail, Patreon or GitHub don't work. On Windows, no MTU means sites periodically loading and periodically not. On the other hand, I've been testing with default MTU on Windows WG over v6 with default MTU as I write this comment and everything seems to be fine, all websites I had problem with on Fedora appear to load. Maybe I need to restart my Fedora machine...

EDIT After a sleep/wake cycle on the Fedora machine, no more problems with any website or service using default 1280 MTU.

ochen1 commented 5 months ago

Thank you @LuuOW for your solution. I chose to add the domain to /etc/hosts instead. Here is the automation: nslookup -q=A engage.cloudflareclient.com | awk '/^Address: / {print $2 " engage.cloudflareclient.com"}' | tee -a /etc/hosts

danisztls commented 5 months ago

Cloudflare Warp is a joke.

outusuke commented 3 months ago

im trying to connect using the ipv6 endpoint but im stuck with "warpv6: Sending handshake initiation to peer 13 ([2606:4700:d0::a29f:c001]:2408/0%0)" IPv6 address seems to have an unusual suffix /0%0 at the end, is this normal?

galpt commented 3 months ago

@outusuke

im trying to connect using the ipv6 endpoint but im stuck with "warpv6: Sending handshake initiation to peer 13 ([2606:4700:d0::a29f:c001]:2408/0%0)" IPv6 address seems to have an unusual suffix /0%0 at the end, is this normal?

According to the docs, the IPv6 Range is 2606:4700:100::/48. So I believe the correct Endpoint should be [2606:4700:100::]:2408 but if your ISP don't give IPv6 then you won't be able to reach that.

Simply use 162.159.193.0/24 and you won't have problems connecting to warp. I've tested 162.159.193.1 - 162.159.193.6, they worked fine. Warp should be able to give IPv6 since you have IPv6 Address configured on the wg config (the [Interface] section).. That is if your ISP gave IPv6.

outusuke commented 3 months ago

@outusuke

im trying to connect using the ipv6 endpoint but im stuck with "warpv6: Sending handshake initiation to peer 13 ([2606:4700:d0::a29f:c001]:2408/0%0)" IPv6 address seems to have an unusual suffix /0%0 at the end, is this normal?

According to the docs, the IPv6 Range is 2606:4700:100::/48. So I believe the correct Endpoint should be [2606:4700:100::]:2408 but if your ISP don't give IPv6 then you won't be able to reach that.

the endpoint is correct and i can ping but not connect, i think its a problem with how network-manager handle ipv6 because i can connect using wireguard on android using ipv6 endpoint normally

abuturabofficial commented 3 weeks ago

For my case, on Fedora, the problem was firewalld's this setting IPv6_rpfilter=yes, changing to IPv6_rpfilter=no in the firewalld.conf in the /etc/firewalld/firewalld.conf resolved the issue.

Thanks to @oxwivi for doing the troubleshooting.