Open naveenjohnsonv opened 3 years ago
Hey! I did some research on Cloudflare's infrastructure and possible causes for problems. Here are some tips that might help you.
PersistentKeepalive = 28
in the [Peer]
section. We'll think about adding this by default in the future.wg show
command. When the incoming and outgoing bytes are both more than 0, the issue is most probably caused by your MTU value. Try setting the MTU in the Wireguard config to 1280
, which is the minimum MTU required for IPv6. Many ISPs use internal tunnels nowadays (eg. 6in4) that reduce the possible size of the payload, and since Wireguard doesn't support fragmentation the packets will never arrive. If you can confirm that the tunnel works now, you need to find the maximum MTU value your connection path supports.2408, 500, 1701, 4500
. Maybe it's your ISP.Hope this helps to solve some of your problems.
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.
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
@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:
wgcf
and make a copy of it: Calling my files local.conf
and local2.conf
local
. Here usually my rx
is very low, a few hundred bytes, thus no internet connection.local
is still activated, select local2
. If your rx
goes into kilobytes you most likely have a successful internet connection.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 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.
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?
@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.
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.
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
I resolve this issue by :
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
@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?
@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.
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.).
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.
I resolve this issue by :
- Commenting out IPv4 address
- Change Endpoint port to 500
- Add PersistentKeepalive = 28
- 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
@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/
I resolve this issue by :
cp ./wgcf-profile.conf /etc/wireguard/
wg-quick down wgcf-profile
For some weird reason, this works for me every time. Commenting out both 'Address' lines also works."
@aloptrbl Have you tried using other ports? Refer to the official docs:
- https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/deployment/firewall/#warp-ingress-ip
- https://developers.cloudflare.com/cloudflare-one/connections/connect-devices/warp/deployment/firewall/#warp-udp-ports
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.
@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.
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?
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.
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.
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.
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.
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
Cloudflare Warp is a joke.
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?
@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
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 correctEndpoint
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
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.
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:
Edit from maintainer (26/11/2022):
Some more advise can be found here: https://github.com/ViRb3/wgcf/issues/50#issuecomment-1327944663