It’s probably going to be easier to debug what is wrong with your VPN, since it’s probably not too complex. You’re likely experiencing some name resolution issue caused by the switch to systemd-resolved. I’ve noticed three other complaints from three different people today and yesterday, so it’s not just you, but there are no bug reports yet.
Let’s start with:
$ resolvectl query example.com
To make sure that fails. (Of course, replace example.com with the domain you are actually trying to resolve.) Then:
$ resolvectl dns
$ resolvectl domain
Post the output for all of these commands (you can replace any non-public domain names if you wish). Hopefully something will appear obviously wrong there. For example, mine says:
$ resolvectl domain
Global:
Link 2 (enp4s0): lan
Link 3 (enp6s0):
Link 4 (wlp5s0):
Link 5 (tun0): ~.
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 8 (tun1): redhat.com
This means: send all DNS requests for resources on redhat.com to the DNS server associated with tun1, DNS requests for resources on lan to the DNS server associated with enp4s0, and all other DNS to the DNS server associated with tun0. Then I also have:
$ resolvectl dns
Global:
Link 2 (enp4s0): 192.168.1.1
Link 3 (enp6s0):
Link 4 (wlp5s0):
Link 5 (tun0): 10.8.0.1
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 8 (tun1): 10.11.5.19 10.5.30.160
So, in my case, systemd will direct a request to resolve redhat.com would be sent to 10.11.5.19 or 10.5.30.160 (the DNS servers for my work VPN), while a request for example.com or anything that doesn’t end in redhat.com or lan would go to 10.8.0.1 (the DNS server of my public VPN).
This all should work out-of-the-box, but somehow something has gone wrong in your case. Our quest will be to figure out why. You might need to use dig to test individual DNS servers:
$ dig @8.8.8.8 example.com
This sends a request to resolve example.com to Google’s DNS server. You can try sending that to the servers listed by resolvectl query to see what happens. Replace 8.8.8.8 with the address of the DNS server that you want to test.
Finally, there was a bug in the version of NetworkManager that shipped with F33 that could cause exactly this problem for a small minority of users who connect to misconfigured VPN servers. However, I doubt that affects you, because you upgraded from F32, so you should have the most recent NetworkManager update already. But just to be certain, please run rpm -qi NetworkManager and verify that you have version 1.26.4 (you probably do). If your NetworkManager is older than that (unlikely) then an upgrade is warranted.