Launchpad has imported 26 comments from the remote bug at https://bugzilla.redhat.com/show_bug.cgi?id=1892283.
If you reply to an imported comment from within Launchpad, your comment will be sent to the remote bug automatically. Read more about Launchpad's inter-bugtracker facilities at https://help.launchpad.net/InterBugTracking. ------------------------------------------------------------------------ On 2020-10-28T11:54:27+00:00 benedikt wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/4 ------------------------------------------------------------------------ On 2020-10-28T12:26:16+00:00 jan.public wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/5 ------------------------------------------------------------------------ On 2020-10-28T12:38:57+00:00 jan.public wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/6 ------------------------------------------------------------------------ On 2020-10-28T12:54:21+00:00 thaller wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/7 ------------------------------------------------------------------------ On 2020-10-28T14:03:47+00:00 benedikt wrote: 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 Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/8 ------------------------------------------------------------------------ On 2020-10-28T16:56:12+00:00 jan.public wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/9 ------------------------------------------------------------------------ On 2020-10-28T21:21:39+00:00 thaller wrote: @Michael, does this ring a bell? Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/10 ------------------------------------------------------------------------ On 2020-10-28T21:30:56+00:00 mcatanza wrote: (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.... Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/11 ------------------------------------------------------------------------ On 2020-10-29T08:36:30+00:00 jan.public wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/12 ------------------------------------------------------------------------ On 2020-10-29T08:57:42+00:00 benedikt wrote: 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): Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/13 ------------------------------------------------------------------------ On 2020-10-29T18:23:41+00:00 mcatanza wrote: (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 (virbr0-nic): > Link 5 (tun0): This is a problem. ~. means all your DNS is sent to the DNS server corresponding to wlp58s0. What you want to see would be either this (Example 1): Global: Link 2 (wlp58s0): Link 3 (virbr0): Link 4 (virbr0-nic): Link 5 (tun0): ~. which means "all DNS should go to the VPN," or perhaps this (Example 2): Global: Link 2 (wlp58s0): ~. Link 3 (virbr0): Link 4 (virbr0-nic): Link 5 (tun0): example.com which means "example.com DNS goes to the VPN, all other DNS goes to interface DNS." Example 1 corresponds to NetworkManager's default settings (good for public VPN services), and Example 2 corresponds to checking the checkbox "Use this connection only for resources on its own network" in NetworkManager settings (good for corporate VPNs). I guess you want to match Example 2, because you mention you're having trouble resolving internal names, so I guess it's a corporate VPN. What I don't understand is how you wound up in such a weird state. If /etc/resolv.conf points to /var/run/NetworkManager/resolv.conf, then NetworkManager doesn't realize systemd-resolved is running at all, and won't attempt to use split DNS, so this trouble is expected. But if /etc/resolv.conf points to the stub resolver, NetworkManager should configure systemd-resolved to match one of my two examples, yet that has not happened in your case. I don't know why. > 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): This isn't good. Ideally your VPN servers would be listed under Link 5 (tun0) rather than Global. Forget about this case: let's not bother with /var/run/NetworkManager/resolv.conf. > 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): This is a little better, in that your VPN nameservers are no longer listed in the wrong place. But they're not listed in the right place either. That is strange. You can try to manually fix it. Let's say you want DNS for your internal corporate domain, example.com, to be resolved over VPN, and everything else to be resolved by your ISP, then you could try (untested): $ sudo nmcli connection modify tun0 ipv4.dns-search ~example.com ipv4.dns 1.2.3.4 Of course, replace example.com with your internal domain, and 1.2.3.4 with the desired internal DNS server. But while manually fixing it is fine, I wish I knew how it got so messed up in the first place! Because so long as /etc/resolv.conf is symlinked to systemd-resolved, NetworkManager should take care of all this for you. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/14 ------------------------------------------------------------------------ On 2020-10-30T10:08:20+00:00 thaller wrote: > 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/15 ------------------------------------------------------------------------ On 2020-10-30T15:24:54+00:00 mcatanza wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/16 ------------------------------------------------------------------------ On 2020-10-30T15:46:12+00:00 benedikt wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/17 ------------------------------------------------------------------------ On 2020-10-30T16:28:10+00:00 mcatanza wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/18 ------------------------------------------------------------------------ On 2020-11-08T20:28:51+00:00 dev wrote: 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' Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/19 ------------------------------------------------------------------------ On 2020-11-08T22:10:58+00:00 mcatanza wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/20 ------------------------------------------------------------------------ On 2020-11-09T18:17:18+00:00 dev wrote: (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" Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/21 ------------------------------------------------------------------------ On 2020-11-09T18:32:48+00:00 mcatanza wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/22 ------------------------------------------------------------------------ On 2020-11-09T18:35:47+00:00 mcatanza wrote: 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). Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/23 ------------------------------------------------------------------------ On 2020-11-09T19:12:51+00:00 dev wrote: 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" Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/24 ------------------------------------------------------------------------ On 2020-11-09T19:25:22+00:00 jan.public wrote: > Why is there no tun interface? Maybe because I'm using strongswan, not openvpn? Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/25 ------------------------------------------------------------------------ On 2020-11-11T08:05:37+00:00 jan.public wrote: Maybe this Ubuntu bug is related: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256 Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/26 ------------------------------------------------------------------------ On 2020-11-11T14:53:58+00:00 mcatanza wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/27 ------------------------------------------------------------------------ On 2020-12-01T09:06:04+00:00 jan.public wrote: (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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/29 ------------------------------------------------------------------------ On 2021-11-04T16:53:06+00:00 bcotton wrote: 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. Reply at: https://bugs.launchpad.net/ubuntu/+source/network-manager- strongswan/+bug/1864256/comments/33 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1864256 Title: Network-manager-strongswan does not update DNS in systemd-resolved To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/network-manager-strongswan/+bug/1864256/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
