After I connect to my company VPN system cannot resolve company urls, but if I restart systemd-resolved service averything works as supposed to be. Any ideas?
If it happen each time you start the PC/laptop? Or it’s only happen once after the setup?
Every time when I enable VPN in network settings I must restart service.
May be you want to read this systemd doc. You can skip everything and directly go to part How to Implement this in Your VPN Software especially on example part of corporate VPN.
I found out that my DNS is set up to wrong IP when I enable VPN, but i have no idea why it’s acting like this:
After enable VPN:
Link 15 (tun0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8
DNS Servers: 172.16.53.8 8.8.8.8
DNS Domain: in.xxx.sk
When I restarted systemd-resolve
Link 15 (tun0)
Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 172.16.53.8
DNS Servers: 172.16.53.8 8.8.8.8
DNS Domain: in.xxx.sk
When connected to a VPN provider, the DNS settings are supposed to be changed to those of the VPN provider, or you would have what is called a “DNS leak”. What I don’t understand is, why do you have to restart systemd-resolved for it to take effect?
Yes, it will change, the problem is that the company network is set up as a fallback DNS server 8.8.8.8.8, which for some reason system-resolved prefers over the internal dns server (172…). I should debug it, but I haven’t figured out how to enable some debug mod on systemd-resolve 
Confirming similar behavior: About once per week I find I need to do sudo systemctl restart systemd-resolved to switch back to the correct DNS server expected by my work’s VPN.
Additional details on my situation: I’m on Fedora 34 and I use GitHub - dlenski/gp-saml-gui: Interactively authenticate to GlobalProtect VPNs that require SAML to connect to a Palo Alto (AnyConnect protocol) VPN. I think I won’t need that in a few months when OpenConnect itself gets the single-sign-on functionality (related: Support AnyConnect single-sign-on-v2 (!75) · Merge requests · OpenConnect VPN projects / OpenConnect · GitLab).
Could that be caused by his use of a custom (google) dns server instead of the default server configured by fedora.
I would venture that he may have changed /etc/resolv.conf from the default link to a file that contains his name server info.
The default on fedora 35 is
$ ls -ld /etc/resolv.conf
lrwxrwxrwx. 1 root root 39 Oct 19 2020 /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
Changing that file may prevents systemd-resolved from doing its job properly. Before I start my vpn I see:
$ cat /etc/resolv.conf
# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
....
nameserver 127.0.0.53
options edns0 trust-ad
search .
Which is the content of the linked file.
When I start my vpn that file is changed to
$ cat /etc/resolv.conf
nameserver 10.0.0.243
$ ls -ld /etc/resolv.conf
-rw-r--r--. 1 root root 22 Feb 2 09:40 /etc/resolv.conf
$ file /etc/resolv.conf
/etc/resolv.conf: ASCII text
When I stop the vpn it reverts back to the original link.
I found that my DHCP lease is 8 days, which corresponds roughly to my “once per week” observation.
So, probably, in my case, the DHCP lease expires and, when it renews, the DNS servers specified through DHCP overwrite what the VPN set.
I inspected the reply from the DHCP server like this:
In one terminal, I issued the following command:
sudo tcpdump -l -vnes0 -i eno1 port 67 or port 68 \
| grep -Fi 'Reply' --after-context=13
In another terminal window, I brought down and back up the network connection:
nmcli con down id 'Wired connection 1'
nmcli con up id 'Wired connection 1'
The result in the first terminal (partially redacted):
tcpdump: listening on eno1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
###.23.1.50.bootps > 255.255.255.255.bootpc: BOOTP/DHCP, Reply, length 334, xid 0xe8c398ae, Flags [none]
Your-IP ###.23.1.131
Client-Ethernet-Address c0:2e:ba:66:24:c4
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message (53), length 1: ACK
RN (58), length 4: 345600
RB (59), length 4: 604800
Lease-Time (51), length 4: 691200
Server-ID (54), length 4: ###.23.1.50
Subnet-Mask (1), length 4: 255.255.255.0
Domain-Name-Server (6), length 28: 192.168.10.115,###.23.1.40,###.23.1.20,192.168.10.116,###.171.3.13,###.171.1.1,###.23.1.50
Domain-Name (15), length 22: "domain.name.goes.here^@"
Default-Gateway (3), length 4: ###.23.1.1
The Lease-Time of 691200 seconds corresponds to 8 days.
Perhaps something similar is happening in your case.