VPN connection blocking IPv6 and ping utility

Ever since I repaired my EFI bootloader, Fedora 37 (and 38 now after upgrading) does not resolve DNS in the terminal.

Before I followed the Fedora Wiki’s guide, I unsuccessfully followed this guide to repair it:

and notably the section under Restore DNS - I’m not sure whether that’s relevant or not, but I still included it below.

Your network connection inside the chroot will probably not work as it should. While pings should work, sometimes DNS resolving does not work due to a broken / invalid /etc/resolv.conf. In my case, resolv.conf was an invalid symlink. I replaced it like this:

mv /etc/resolv.conf /etc/resolv.conf.bak
touch /etc/resolv.conf

Now put the following into /etc/resolv.conf


(… or select another DNS resolver IP address. I chose “Quad Nine”).

… check if resolving public names does work, now:

ping thomas-leister.de

I can still use the Internet and connect to websites successfully, but pinging websites like Google or Youtube in terminal does not work.

For example,

user@fedora ~]$ ping -c 3 redhat.com
PING redhat.com ( 56(84) bytes of data.

redhat.com ping statistics —
3 packets transmitted, 0 received, 100% packet loss, time 2080ms

1 Like

If you can ping to redhat.com and the IP address is displayed, DNS resolve did its job.
By the way, I get the same result for redhat. Not every site is willing to reply to pings, but google normally does, www.redhat.com works too.

Optimal current Fedora configuration is to have systemd-resolved up and running,
and /etc/resolv.conf should be a symlink to /run/systemd/resolve/stub-resolv.conf

This symlink is invalid if systemd-resolved is down for some reasons.

Check with “resolvectl” and “resolvectl query” the functionality, then it should be fine.

1 Like

Thank you for the response. So, I have a network connectivity problem instead of one with name resolution.

‘resolvectl’ and ‘resolvectl query’ worked fine

[user@fedora ~]$ resolvectl query redhat.com
redhat.com: – link: wg-mullvad – link: wg-mullvad

– Information acquired via protocol DNS in 95.3ms.
– Data is authenticated: no; Data was acquired via local or encrypted transport: no
– Data from: network

Looking through this guide:

[user@fedora ~]$ ping -c 1 www.google.com
PING www.google.com(wv-in-f104.1e100.net (2607:f8b0:4004:c1b::68)) 56 data bytes
From fedora (ipv6) icmp_seq=1 Destination unreachable: Port unreachable

www.google.com ping statistics —
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

It looks like it’s using my actual IPv6 address over the one that my VPN connection should be using, and that’s why it’s unable to ping websites.

Adding some information: To perform DNS queries in your terminal you should use nslookup. As some websites does not reply to pings.

nslookup google.com

Non-authoritative answer:
Name:   google.com
Name:   google.com
Address: 2a00:1450:4002:406::200e

Now I understand. The procedure to fix grub is using chroot, where you run a Live-CD and descend by chroot into the actual system. At that moment, the actual system is not running systemd nor systemd-resolved and the /etc/resolv.conf symlink is broken, that’s why they recommend to make a normal /etc/resolv.conf pointing to
This is only during this chroot, if the system is running again you can recreate the symlink and continue as usual with Fedora standard config.

Now IPv6 and VPN enter the game… Do you have a VPN supporting IPv6? There seem to be not that many. Some VPN’s send IPv6 into the blackhole of a dummy interface which means that any attempt to ping a host via IPv6 will fail. You can check with “ip -6 route get” followed by the IPv6 address of the host you want to check to see the direction the packets go and the source address used.

1 Like

I use Mullvad VPN which supports IPv6. After enabling IPv6 in the app, the ping utility worked.

[user@fedora ~]$ ping -c 3 google.com
PING google.com ( 56(84) bytes of data.
64 bytes from bc-in-f138.1e100.net ( icmp_seq=1 ttl=106 time=14.0 ms
64 bytes from bc-in-f138.1e100.net ( icmp_seq=2 ttl=106 time=14.1 ms
64 bytes from bc-in-f138.1e100.net ( icmp_seq=3 ttl=106 time=14.4 ms

Thanks so much for your help!