Internet access does not work (system issue)

[naveenjohnsonv]

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 Internet access does not work (system issue) #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 Internet access does not work (abuse prevention) #158.

Edit from maintainer (26/11/2022):

Some more advise can be found here: #50 (comment)

[matroot]

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]

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]

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]

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]

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]

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]

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]

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

[ghost]

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]

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]

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]

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]

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]

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]

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

[gothmog123]

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

[berkant]

@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]

@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]

@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]

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]

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

[yura-pakhuchiy]

@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]

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

wgcf/cmd/generate/generate.go

Lines 49 to 55 in 1780811

	profile, err := wireguard.NewProfile(&wireguard.ProfileData{
	PrivateKey: viper.GetString(config.PrivateKey),
	Address1: thisDevice.Config.Interface.Addresses.V4,
	Address2: thisDevice.Config.Interface.Addresses.V6,
	PublicKey: thisDevice.Config.Peers[0].PublicKey,
	Endpoint: thisDevice.Config.Peers[0].Endpoint.Host,
	})

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]

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]

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]

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]

@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?

[galpt]

@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]

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.

• Changing Endpoint to be a specific IPv4 IP. Didn't help.
• Changing MTU.
• Disabling IPv6 completely (just resulted in no networking at all).
• Sniffing the tunnel interface I can see outgoing IPv4 traffic (so outbound routing it okay), but no replies. IPv6 works in both directions.

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]

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]

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]

@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]

@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]

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

[galpt]

@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/

[nazdridoy]

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]

@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.

[galpt]

@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]

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]

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]

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:

• 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

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]

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]

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]

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

[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?

[galpt]

@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]

@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]

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.