Network-manager-strongswan does not update DNS in systemd-resolved

[Julian Petri]

Ubuntu release: 19.10
Package version: 1.4.4-2

Situation:
I have configured an IKEv2/IPsec connection to my workplace in the Network Manager GUI. Two IPv4 DNS servers separated by commas are configured in the connection profile and "Automatic" is turned off for DNS.
The connection starts up fine and I can ping machines in the remote network.

Expectation:
The two DNS servers will be configured using systemd-resolved so they are used to resolve remote machine names.
systemd-resolve --status | grep "Servers"
is supposed two show the two servers.

What happened instead:
systemd-resolve --status | grep "Servers"
only shows my local DNS server, just as before the VPN connection was established. Restarting systemd-resolved.service does not change this.

[Julian Petri (petroy)]

I found out that this is related to https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320
Network manager *does* add the DNS servers, but they are never used. The workaround in comment #57 fixes the problem.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Jan Vlug (z-j)]

I have this issue as well. However, the instructions given in https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1624320/comments/57 do not solve the issue for me.

When connecting the strongswan VPN, I see that the /run/systemd/resolve/resolv.conf file is touched (the timestamp of the file changes), but the content does not change.

Automatic nor manual DNS servers in the VPN settings do work.

I tested manual modifying the /run/systemd/resolve/resolv.conf by changing the nameserver. This works once, but this change is not persisted, as the file is overwritten each time.

However the file /run/NetworkManager/no-stub-resolv.conf does contain the nameservers that are automatically provided by the VPN connection.

This solved the issue for me:
$ sudo rm /etc/resolv.d
$ sudo ln -s /run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf

I am running Ubuntu Desktop, not Ubuntu Server (if that is relevant).
It is fully up to date: Linux myhost 5.4.0-48-generic #52-Ubuntu SMP Thu Sep 10 10:58:49 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

[benedikt (benedikt-redhat-bugs-1)]

Description of problem:

When using NetworkManager to connect to a VPN where OpenVPN pushes DNS configuration from the server (via the dhcp-option setting), these servers are correctly added to /etc/resolv.conf. However, since Fedora 33, the default for name resolution is systemd-resolved, which appears to ignore /etc/resolv.conf and the configured name servers are not used.

Version-Release number of selected component (if applicable):

NetworkManager-openvpn-1:1.18.12-1.fc33.1

How reproducible:

Always

Steps to Reproduce:
1. Connect to an OpenVPN network that configures custom name servers via dhcp-option
2. Observe that these name servers are added to /etc/resolv.conf
3. Try to resolve internal names only served by the custom name servers

Actual results:

Name resolution fails as systemd-resolved ignores the configured name servers

Expected results:

The configured name servers are used and internal names resolve successfully

Additional info:

As a workaround, systemd-resolved can be circumvented by adding "dns=default" to the [main] section in /etc/NetworkManager/NetworkManager.conf

[jan.public (jan.public-redhat-bugs)]

Confirming this with an openswan VPN on a freshly to Fedora 33 upgraded system.
The DNS servers provided by the VPN are added to the /etc/resolv.conf
nslookup can resolve VPN internal host names.
Browsers state that they cannot find the site.

[jan.public (jan.public-redhat-bugs)]

The suggested workaround to add dns=default to the [main] section in /etc/NetworkManager/NetworkManager.conf does not solve the issue that the browsers cannot resolve the internal host names in my case.

[thaller (thaller-redhat-bugs)]

there are various ways how DNS (with or without NetworkManager) can be configured.

Also, it doesn't seem you are using the default configuration of Fedora 33, where systemd-resolved is used. So, to fully understand the problem, you would have to provide how your system is configured.

For example,

with systemd-resolved, commonly /etc/resolv.conf would be symlinked to a file as explained in `man systemd-resolved`. In that case systemd-resolved will mostly ignore /etc/resolv.conf, and /etc/resolv.conf is commonly not used by glibc resolver (which -- depending on your configuration -- uses NSS modules to directly talk to systemd-resolved (`man nsswitch.conf`)). Thus the symlinked /etc/resolv.conf is mostly not used, but see how this works in `man systemd-resolved`.

Anyway. You need to share how exactly your system is configured.

Possibly, just collect a complete level=TRACE log that shows the issue. Read https://cgit.freedesktop.org/NetworkManager/NetworkManager/tree/contrib/fedora/rpm/NetworkManager.conf#n28 for hints about logging (and note the comment about private data in log files).

[benedikt (benedikt-redhat-bugs-1)]

The system I am working with has been upgraded from F32. /etc/resolv.conf is a symlink to /var/run/NetworkManager/resolv.conf. It seems to me that in this case systemd-resolved should be in "consumer" mode and use the nameservers provided there (as stated in the fourth bullet point in the /etc/resolv.conf section of the systemd-resolved man page), but that doesn't seem to happen.

If I use any of the other options listed in that manpage as link targets for /etc/resolv.conf, and connect to the VPN, name resolution for internal names still fails. systemd-resolved doesn't seem to learn about the new servers, so the stub resolver won't resolve those names, and they don't get added to /run/systemd/resolve/resolv.conf either. /var/run/NetworkManager/resolv.conf appears to be the only place where they show up.

My nsswitch.conf provides the following configuration for gethostbyname: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

[jan.public (jan.public-redhat-bugs)]

I did some testing with the following command:
# resolvectl dns

This are the results is different situations:
No VPN, IPv6 enabled (automatic):
# resolvectl dns
Global: 84.116.46.21 84.116.46.20 2001:b88:1002::10 2001:b88:1202::10 2001:730:3e42:1000::53
Link 2 (enp35s0): 84.116.46.21 84.116.46.20 2001:b88:1002::10 2001:b88:1202::10 2001:730:3e42:1000::53
Link 3 (virbr1):
Link 4 (virbr1-nic):
Link 5 (virbr0):
Link 6 (virbr0-nic):

VPN enabled, IPv6 enabled (automatic):
# resolvectl dns
Global: 192.168.253.4 192.168.253.5 84.116.46.21 84.116.46.20 2001:b88:1002::10 2001:b88:1202::10 2001:730:3e42:1000::53
Link 2 (enp35s0): 84.116.46.21 84.116.46.20
Link 3 (virbr1):
Link 4 (virbr1-nic):
Link 5 (virbr0):
Link 6 (virbr0-nic):

No VPN, IPv6 disabled:
# resolvectl dns
Global: 84.116.46.21 84.116.46.20
Link 2 (enp35s0): 84.116.46.21 84.116.46.20
Link 3 (virbr1):
Link 4 (virbr1-nic):
Link 5 (virbr0):
Link 6 (virbr0-nic):

VPN enabled, IPv6 disabled:
# resolvectl dns
Global: 192.168.253.4 192.168.253.5 84.116.46.21 84.116.46.20
Link 2 (enp35s0): 84.116.46.21 84.116.46.20
Link 3 (virbr1):
Link 4 (virbr1-nic):
Link 5 (virbr0):
Link 6 (virbr0-nic):

The DNS servers provided by the VPN are: 192.168.253.4,192.168.253.5
My /etc/resolv.conf is a symbolic link to /var/run/NetworkManager/resolv.conf
I also upgraded from Fedora 32 to Fedora 33.
I still have another computer running Fedora 32, where the DNS for resolving VPN host works fine. So I can do some tests or comparisons if this would help.

[thaller (thaller-redhat-bugs)]

@Michael, does this ring a bell?

[mcatanza (mcatanza-redhat-bugs)]

(In reply to Benedikt Gollatz from comment #4)
> The system I am working with has been upgraded from F32. /etc/resolv.conf is
> a symlink to /var/run/NetworkManager/resolv.conf. It seems to me that in
> this case systemd-resolved should be in "consumer" mode and use the
> nameservers provided there (as stated in the fourth bullet point in the
> /etc/resolv.conf section of the systemd-resolved man page), but that doesn't
> seem to happen.

OK, in this mode, systemd-resolved should indeed be in consumer mode. It should try each server listed in /etc/resolv.conf one at a time. If the first-listed server says the name doesn't exist, then it stops and will not check with the next server.

Have you both *intentionally* configured that setup? I highly recommend deleting /etc/resolv.conf and symlinking it to ../run/systemd/resolve/stub-resolv.conf. This is Fedora's default configuration, and is *much* better supported. I haven't invested any effort into testing non-default configurations.

I understand that some users who have upgraded from much older Fedora releases might wind up with /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf with no user interaction. If so, that's a Fedora bug, and we should probably one-time clobber that configuration in an upgrade scriptlet to ensure everyone who hasn't intentionally manually configured /etc/resolv.conf should get /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf.

> If I use any of the other options listed in that manpage as link targets for
> /etc/resolv.conf, and connect to the VPN, name resolution for internal names
> still fails. systemd-resolved doesn't seem to learn about the new servers,
> so the stub resolver won't resolve those names, and they don't get added to
> /run/systemd/resolve/resolv.conf either. /var/run/NetworkManager/resolv.conf
> appears to be the only place where they show up.

Hmmm, that is weird. Can you please post the output of 'resolvectl domain' and 'resolvectl dns'? My suspicion is you don't have DNS domains configured properly. NetworkManager should handle that for you so you don't have to think about it, but I guess somehow it's not happening....

[jan.public (jan.public-redhat-bugs)]

Yesterday, I had host name resolution shortly working after fiddling with nsswitch.conf IIRC. I noticed that I had also an /etc/nsswitch.conf.rpmnew file with date: 2020-08-06.
After rebooting my resolving of inner VPN hosts does not work any more. Unfortunately, I'm not experienced in this area, apologies for the vague report, but I hope it might give you some hints.
It could be that in the past I made changes to the nsswitch.conf, and that that file was not updated any more because of this. I have been using and updating my current system from many Fedora version back.

My nsswitch.conf.rpmnew contains this line:
hosts: files dns myhostname

My current is now a copy of the nsswitch.conf.rpmnew, but I modified the hosts: line to:
hosts: files resolve myhostname
In this configuration inner VPN host names do not resolve

Just now I changed the line back to:
hosts: files dns myhostname
I did:
# systemctl restart NetworkManager
Connected the VPN again via the GUI (first time I got an error, second time was successful)
# resolvectl dns
Global: 192.168.253.4 192.168.253.5 84.116.46.21 84.116.46.20
Link 2 (enp35s0): 84.116.46.21 84.116.46.20
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (virbr1):
Link 6 (virbr1-nic):
# resolvectl domain
Global:
Link 2 (enp35s0): ~.
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (virbr1):
Link 6 (virbr1-nic):
But the dns does not work for VPN internal hosts.

[benedikt (benedikt-redhat-bugs-1)]

I don't remember changing the /etc/resolv.conf symlink; my guess is that the symlink remains unchanged when upgrading from an earlier version of Fedora. The internal nameservers get added to the top, so that shouldn't be the issue.

When connecting to the VPN, resolvectl domain says the following, irrespective of the /etc/resolv.conf symlink.

Global:
Link 2 (wlp58s0): ~.
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0):

If I use /var/run/NetworkManager/resolv.conf, resolvectl dns says this:

Global: <VPN nameservers> <default nameservers>
Link 2 (wlp58s0): <default nameservers>
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0):

However, if i use the stub resolver, the VPN nameservers do not show up at all:

Global:
Link 2 (wlp58s0): <default nameservers>
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 6 (tun0):

[mcatanza (mcatanza-redhat-bugs)]

(In reply to Jan Vlug from comment #8)
> Yesterday, I had host name resolution shortly working after fiddling with
> nsswitch.conf IIRC.

Did you read the warning telling you not to edit it at that top of that file? If you modified it outside authselect, you'll want to regenerate it to get back to a consistent state:

# authselect apply-changes --force

Otherwise future authselect operations will fail.

The hosts like in /etc/nsswitch should look like this:

hosts: files mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] myhostname dns

If you want to change it, you need to edit /etc/authselect/user-nsswitch.conf. Never edit /etc/nsswitch.conf directly.

(In reply to Jan Vlug from comment #8)
> Just now I changed the line back to:
> hosts: files dns myhostname

This is legacy mode. nss-dns will read /etc/resolv.conf instead of talking directly to systemd-resolved. There's no good reason to do that, so I recommend switching back to our defaults.

> # systemctl restart NetworkManager
> Connected the VPN again via the GUI (first time I got an error, second time
> was successful)
> # resolvectl dns
> Global: 192.168.253.4 192.168.253.5 84.116.46.21 84.116.46.20
> Link 2 (enp35s0): 84.116.46.21 84.116.46.20
> Link 3 (virbr0):
> Link 4 (virbr0-nic):
> Link 5 (virbr1):
> Link 6 (virbr1-nic):
> # resolvectl domain
> Global:
> Link 2 (enp35s0): ~.
> Link 3 (virbr0):
> Link 4 (virbr0-nic):
> Link 5 (virbr1):
> Link 6 (virbr1-nic):
> But the dns does not work for VPN internal hosts.

I'm confused. You have no VPN interfaces here. Is your VPN enabled? Why is there no tun interface?

You have only one DNS domain -- the global domain ~. -- so all your DNS should go to 84.116.46.21 or 84.116.46.20. Those are public addresses, so no surprise that you're unable to use public DNS servers to resolve internal names.

Likely as not, your case is a separate problem from Benedikt's. Since you've been doing some custom configuration, I'm not convinced there's a software bug here.

(In reply to Benedikt Gollatz from comment #9)
> I don't remember changing the /etc/resolv.conf symlink; my guess is that the
> symlink remains unchanged when upgrading from an earlier version of Fedora.
> The internal nameservers get added to the top, so that shouldn't be the
> issue.

Well... it's not the issue, but it also doesn't make sense. You really want /etc/resolv.conf to only list systemd-resolved itself, 127.0.0.53. Otherwise you're going to have inconsistent behavior. Applications that read /etc/resolv.conf directly will ignore your DNS settings configured by NetworkManager and systemd-resolved.

I suspect this is a NetworkManager packaging bug. I suspect the NetworkManager package previously symlinked /etc/resolv.conf to /var/run/NetworkManager/resolv.conf. We probably need a scriptlet somewhere to clean this up, probably in the NetworkManager package, or perhaps in the systemd package. So while I do think we have a Fedora bug here, that also doesn't explain what's going wrong for you.

> When connecting to the VPN, resolvectl domain says the following,
> irrespective of the /etc/resolv.conf symlink.
>
> Global:
> Link 2 (wlp58s0): ~.
> Link 3 (virbr0):
> Link 4 (...

[thaller (thaller-redhat-bugs)]

> I suspect this is a NetworkManager packaging bug. I suspect the NetworkManager package previously symlinked /etc/resolv.conf to /var/run/NetworkManager/resolv.conf.

Maybe NetworkManager did that. But it only did that a (relatively) long time ago, and stopped doing that since. In that case, fix it by creating /etc/resolv.conf to be a file or (a different) symlink as desired.

Nowadays (including Fedora 32), NetworkManager never writes /etc/resolv.conf as a symlink. /etc/resolv.conf being a symlink is taken as a hint/configuration by the administrator who is in charge of resolv.conf. With `rc-manager=symlink` setting (the default, see `man NetworkManager.conf`) it would do nothing if it finds a symlink and otherwise write /etc/resolv.conf as a regular file.

> We probably need a scriptlet somewhere to clean this up, probably in the NetworkManager package, or perhaps in the systemd package. So while I do think we have a Fedora bug here, that also doesn't explain what's going wrong for you.

Regardless whether NetworkManager did it or the user, symlinking /etc/resolv.conf to /var/run/NetworkManager/resolv.conf is a possible, sensible configuration on its own (of course not in combination with using systemd-resolved). I think the upgrade to Fedora 33 should only enable systemd-resolved if /etc/resolv.conf is a regular file. And -- as already gets checked -- that it has the "generated by NetworkManager` line.

Alternatively, upgrade could also migrate such systems to systemd-resolved and reset the /etc/resolv.conf symlink. But that might not be what the user wants....

I find this bug report rather confusing. There are countless ways how to configure DNS (some working/sensible, some not). But what matters it the initial configuration, directly after upgrade -- and to find out what went wrong, why is it no longer working.

Sure, we should find out how to best fix the misconfiguration, but let's focus on first understanding what the original report and the actual misconfiguration is (and how it happened).

Note that even if the upgrade went as desired, enabling systemd-resolved means to switch from plain /etc/resolv.conf to enable split DNS. That *is* an intentional change in behavior, and you can have a DNS configuration (in NetworkManager) that happened to work previously, but stops after switching to split DNS. Of course, in most cases both should work similar enough.

[mcatanza (mcatanza-redhat-bugs)]

(In reply to Thomas Haller from comment #11)
> Regardless whether NetworkManager did it or the user, symlinking
> /etc/resolv.conf to /var/run/NetworkManager/resolv.conf is a possible,
> sensible configuration on its own (of course not in combination with using
> systemd-resolved). I think the upgrade to Fedora 33 should only enable
> systemd-resolved if /etc/resolv.conf is a regular file. And -- as already
> gets checked -- that it has the "generated by NetworkManager` line.

Hm, we do not touch /etc/resolv.conf during upgrade if it is already a symlink, but we do enable systemd-resolved regardless. So I think that explains how users wound up in this scenario. They presumably upgraded from very old Fedora. Assuming they didn't manually configure this, it's Fedora's job to handle that. So I still think that's a Fedora bug. We ought to either (a) assume that anyone using /var/run/NetworkManager/resolv.conf is doing so due to our mistake, and migrate them to stub-resolv.conf, or (b) not enable systemd-resolved in this scenario.

Anyway, that doesn't fully explain the weird DNS configurations we're seeing.

> I find this bug report rather confusing. There are countless ways how to configure DNS (some working/sensible, some not). But what matters it the initial configuration, directly after upgrade -- and to find out what went wrong, why is it no longer working.

Well, yes, that's the problem. Clearly something else has gone wrong somewhere for both these users, but to have an actionable bug report, we need to know exactly what. These configurations are weird, and I don't see how they could have happened. Without knowing how it happened, we don't have much to go on, and certainly no evidence of another bug, and also no evidence that it is the same problem for both users.

[benedikt (benedikt-redhat-bugs-1)]

If I configure /etc/resolv.conf to be symlinked to ../run/systemd/resolve/stub-resolv.conf, the bug remains nearly the same. The original report changes insofar as new nameservers don't get added to /etc/resolv.conf, however, the do not show up in the output of "resolvectl dns" either, and the search domain for the root zone remains with the physical network interface rather than being switched to the tunnel interface. Unless there is a different bit of hidden configuration, it seems that even fresh installations of F33 would encounter the problem of non-resolving internal names.

I can configure DNS servers and search domain manually via nmcli; upon connection these are then added to the tunnel interface and resolving internal names works.

[mcatanza (mcatanza-redhat-bugs)]

(In reply to Benedikt Gollatz from comment #13)
> Unless there is a different bit of hidden configuration, it seems
> that even fresh installations of F33 would encounter the problem of
> non-resolving internal names.

Well I doubt it, because if so, openvpn would be broken for everyone. You should get one of the following behaviors for 'resolvectl domain'. With "use this connection only for resources on its network" unchecked (default behavior, good for public VPNs):

Global:
Link 2 (wlp58s0):
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0): ~.

Or, with "use this connection only for resources on its network" checked (good for corporate VPNs):

Global:
Link 2 (wlp58s0): ~.
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 5 (tun0): example.com

where example.com is the domain of your VPN. Since you are trying to resolve internal names, I assume you're using a corporate VPN and that is the setup you want? Can you please confirm that you have that button checked?

In both cases, 'resolvectl dns' should look like this:

Global:
Link 2 (wlp58s0): <default nameservers>
Link 3 (virbr0):
Link 4 (virbr0-nic):
Link 6 (tun0): <VPN nameservers>

That's all rehashed from comment #10, but I post it again here for clarity. I use both configurations every day, at the same time, and it all works as expected for me. Deviation from the above is unexpected and unusual. Something strange is happening with your case, and we need to figure out why.

[dev (dev-redhat-bugs)]

After upgrade to F33 I also have a problem with DNS and VPN (openvpn).

My normal use case is a connection with activated "use this connection only for resources on its network" not working anymore:

resolvectl dns
Global:
Link 2 (enp0s31f6):
Link 3 (wlp3s0): <home_router_ipv4> <home_router_ipv6>
Link 4 (virbr1):
Link 5 (virbr1-nic):
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 12 (tun0):

resolvectl domain
Global:
Link 2 (enp0s31f6):
Link 3 (wlp3s0): ~. fritz.box
Link 4 (virbr1):
Link 5 (virbr1-nic):
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 12 (tun0):

If I uncheck this option and reconnect, all works as expected:

resolvectl dns
Global:
Link 2 (enp0s31f6):
Link 3 (wlp3s0): <home_router_ipv4>
Link 4 (virbr1):
Link 5 (virbr1-nic):
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 13 (tun0): <VPN nameservers>

resolvectl domain
Global:
Link 2 (enp0s31f6):
Link 3 (wlp3s0): fritz.box
Link 4 (virbr1):
Link 5 (virbr1-nic):
Link 6 (virbr0):
Link 7 (virbr0-nic):
Link 13 (tun0): ~.

My '/etc/resolv.conf' is a symlink to '../run/systemd/resolve/stub-resolv.conf'

[mcatanza (mcatanza-redhat-bugs)]

(In reply to Illya from comment #15)
> After upgrade to F33 I also have a problem with DNS and VPN (openvpn).
>
> My normal use case is a connection with activated "use this connection only
> for resources on its network" not working anymore:
>
> resolvectl dns
> Global:
> Link 2 (enp0s31f6):
> Link 3 (wlp3s0): <home_router_ipv4> <home_router_ipv6>
> Link 4 (virbr1):
> Link 5 (virbr1-nic):
> Link 6 (virbr0):
> Link 7 (virbr0-nic):
> Link 12 (tun0):

Yeah, that looks like the same issue. I wonder why NetworkManager is not configuring a DNS domain for tun0.

[dev (dev-redhat-bugs)]

(In reply to Michael Catanzaro from comment #16)
> (In reply to Illya from comment #15)
> > After upgrade to F33 I also have a problem with DNS and VPN (openvpn).
> >
> > My normal use case is a connection with activated "use this connection only
> > for resources on its network" not working anymore:
> >
> > resolvectl dns
> > Global:
> > Link 2 (enp0s31f6):
> > Link 3 (wlp3s0): <home_router_ipv4> <home_router_ipv6>
> > Link 4 (virbr1):
> > Link 5 (virbr1-nic):
> > Link 6 (virbr0):
> > Link 7 (virbr0-nic):
> > Link 12 (tun0):
>
> Yeah, that looks like the same issue. I wonder why NetworkManager is not
> configuring a DNS domain for tun0.

The issue is resolved for me.
Our server was not pushing domain options. Change on server side was to add following lines to the '/etc/openvpn/server/server.conf':

push "dhcp-option DOMAIN some-domain.net"
push "dhcp-option DOMAIN some-other-domain.com"

[mcatanza (mcatanza-redhat-bugs)]

Thanks for sharing solution.

I still think it's a NetworkManager bug though, because NetworkManager knows that "use this connection only for resources on its network" without any DNS domains is a nonsensical configuration, and clearly more users are hitting the same problem and won't be able to fix their VPN servers. NetworkManager should set a DNS domain automatically when none are set.

This is actually quite similar to bug #1863041, and probably not specific to the openvpn plugin.

[mcatanza (mcatanza-redhat-bugs)]

BTW to be clear, my proposed expected behavior would be to set the top privately-controlled domain of the VPN's gateway address as a DNS search domain if "use this connection only for resources on its network" is checked and the server does not specify and search domains. Then if you're connecting to an example.com VPN, you'll at least be able to resolve example.com addresses (although resolving non-example.com internal domains will fail).

[dev (dev-redhat-bugs)]

Or the previous behaviour could be restored:
- all DNS traffic goes to VPN DNS if no domains were pushed
- other traffic is routed according to pushed routes

Eventually with the second checkbox "Use this connection's DNS only for resources on its network"

[jan.public (jan.public-redhat-bugs)]

> Why is there no tun interface?

Maybe because I'm using strongswan, not openvpn?

[jan.public (jan.public-redhat-bugs)]

Maybe this Ubuntu bug is related: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1864256

[mcatanza (mcatanza-redhat-bugs)]

That might be your problem, but it is definitely not *this* bug, because Benedikt is not using a strongswan VPN. I think we've reached the point where you really need your own separate bug report for your issue.

[Jan Vlug (z-j)]

I made a mistake in the instruction in comment 3 above. It should be:
$ sudo rm /etc/resolv.conf
$ sudo ln -s /run/NetworkManager/no-stub-resolv.conf /etc/resolv.conf

[jan.public (jan.public-redhat-bugs)]

(In reply to Michael Catanzaro from comment #23)
> That might be your problem, but it is definitely not *this* bug, because
> Benedikt is not using a strongswan VPN. I think we've reached the point
> where you really need your own separate bug report for your issue.

For information, the root cause of the problem with strongswan is described here: https://wiki.strongswan.org/issues/3615.

[Julian Petri (petroy)]

An upstream patch is in the works:
https://wiki.strongswan.org/issues/3615

The workaround instructions work for me.

[Julian Petri (petroy)]

Update: I am on Groovy now. Installing resolvconf and restarting is also a working fix for this problem:
sudo apt install resolvconf

[Julian Petri (petroy)]

Scratch that. It is not. I was confused because the VPN DNS server is actually communicated to systemd-resolve, but it is not set as the "current DNS server".

[bcotton (bcotton-redhat-bugs)]

This message is a reminder that Fedora 33 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '33'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 33 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

[bcotton (bcotton-redhat-bugs)]

Fedora 33 changed to end-of-life (EOL) status on 2021-11-30. Fedora 33 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.