0

I'm having this strange behavior when I connect to my company VPN using barracudavpn (my OS is Fedora 36). After connecting network configuration seems ok:

$ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         10.16.40.1      0.0.0.0         UG    0      0        0 tun0
0.0.0.0         192.168.1.1     0.0.0.0         UG    600    0        0 wlp0s20f3
10.16.40.0      0.0.0.0         255.255.252.0   U     0      0        0 tun0
88.157.223.5    192.168.1.1     255.255.255.255 UGH   0      0        0 wlp0s20f3
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
172.22.0.0      0.0.0.0         255.255.0.0     U     0      0        0 br-533d90405936
192.168.1.0     0.0.0.0         255.255.255.0   U     600    0        0 wlp0s20f3
192.168.1.1     0.0.0.0         255.255.255.255 UH    0      0        0 wlp0s20f3

$ cat /etc/resolv.conf
nameserver 10.0.1.3
nameserver 10.40.0.6
nameserver 10.0.1.2
nameserver 10.40.0.7
nameserver  127.0.0.53
search mycompany.xx home

If I query the DNS for some service it works as expected:

$ nslookup bitbucket.mycompany.xx
Server:     10.0.1.3
Address:    10.0.1.3#53

bitbucket.mycompany.xx  canonical name = app-bitbucket.mycompany.xx.
Name:   app-bitbucket.mycompany.xx
Address: 10.0.1.246

But any other command fails:

$ ping bitbucket.mycompany.xx
ping: bitbucket.mycompany.xx: Name or service not known

What am I missing here?

Vinicius
  • 168
  • 8
  • 1
    Does `resolvectl` show the correct nameservers? – user1686 Jun 30 '22 at 17:26
  • 1
    `nslookup` or `dig` do DNS queries, because it is their job. While on the other hand, `ping` or any other command asks by default the OS to do the name resolution. In turn, the OS can be programmed to do name resolution in many different ways, and not just using the DNS. This is typically controlled by `/etc/nsswitch.conf` and the `hosts` entry. Do check what you have there or at least provide its content. And you do not need to use `ping` (almost always a bad troubleshooting tool), you can just test with `getent`. Otherwise, did you ask your company sys/network admins? – Patrick Mevzek Jun 30 '22 at 17:32
  • `resolvectl status` shows the default DNS, not the VPN DNS. – Vinicius Jun 30 '22 at 17:34
  • @PatrickMevzek My company only supports Ubuntu, and it just works in Ubuntu. The nsswitch config is the default, I now managed to get it working by removing the `resolve [!UNAVAIL=return]` that sits before the `dns`. I still don´t understand why resolve` isn't working. – Vinicius Jun 30 '22 at 17:58
  • @PatrickMevzek Just mounted the Ubuntu partition and looked at its nsswitch.conf and there is no `resolve` for the `hosts` line. That's the problem. (but still, the `resolv.conf` is correct so resolve should work). – Vinicius Jun 30 '22 at 18:02
  • `resolv.conf` is only used directly by programs doing DNS queries. OS level resolution of names (and other stuff), as requested by program, go to `/etc/nsswitch.conf` first to determine if DNS should be used or not – Patrick Mevzek Jun 30 '22 at 19:12
  • In this case, the nsswitch is configured to use resolved and thus OS level resolution is using it. – Vinicius Jun 30 '22 at 21:41

1 Answers1

4

With insights from @PatrickMevzek and @user1686 I managed to understand the problem, so I'll post this answer to help anyone with the same problem.

The barracudavpn program, after the connection, changes /etc/resolv.conf to add the VPN name servers, but by default this file is just ignored by systemd.resolved. From systemd-resolved.service(8) manpage:

To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink to /run/systemd/resolve/stub-resolv.conf, /usr/lib/systemd/resolv.conf or /run/systemd/resolve/resolv.conf.

The default Fedora 36 installation has this:

$ ls -l /etc/resolv.conf
lrwxrwxrwx. 1 root root 39 jun 27 02:54 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf

So just by removing this link (the file will be recreated by systemd-resolved) everything works as intended.

Vinicius
  • 168
  • 8