Dear friends,
From the past week, I have had an issue in that after several hours, some particular sites become inaccessible to me, and can only be accessed if I use restart using sudo systemctl restart systemd-resolved.service
What particular issues cause this? Why did it start a week ago, and has become quite reliable in its annoyance? (I have to say that when I can no longer access this site, I am no longer on Cisco SecureClient VPN, which is also one of the sites which can not be accessed with Cisco SecureClient VPN without restarting systemd-resolved.service, and the site is my worksite domain).
Happy to file bug reports, and to test different things. I am on a fully updated F38.
Many thanks and best wishes, Ranjan
On 09/27/2023 10:14 AM, Ranjan Maitra wrote:
From the past week, I have had an issue in that after several hours, some particular sites become inaccessible to me, and can only be accessed if I use restart using sudo systemctl restart systemd-resolved.service
Before any of us can help you, we need a little more information: what version of Fedora are you using and how long since you last updated your system?
Thanks very much! An mentioned in the original post, I am on a fully updated F38. I update nightly.
$ uname -a Linux 6.4.15-200.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Sep 7 00:25:01 UTC 2023 x86_64 GNU/Linux
Many thanks and best wishes, Ranjan
On Wed Sep27'23 10:24:00AM, Joe Zeff wrote:
From: Joe Zeff joe@zeff.us Date: Wed, 27 Sep 2023 10:24:00 -0600 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 09/27/2023 10:14 AM, Ranjan Maitra wrote:
From the past week, I have had an issue in that after several hours, some particular sites become inaccessible to me, and can only be accessed if I use restart using sudo systemctl restart systemd-resolved.service
Before any of us can help you, we need a little more information: what version of Fedora are you using and how long since you last updated your system?
On 9/27/23 09:14, Ranjan Maitra wrote:
From the past week, I have had an issue in that after several hours, some particular sites become inaccessible to me, and can only be accessed if I use restart using sudo systemctl restart systemd-resolved.service
What particular issues cause this? Why did it start a week ago, and has become quite reliable in its annoyance? (I have to say that when I can no longer access this site, I am no longer on Cisco SecureClient VPN, which is also one of the sites which can not be accessed with Cisco SecureClient VPN without restarting systemd-resolved.service, and the site is my worksite domain).
That is probably relevant. resolved supports split DNS when using a VPN. Try the following commands both while the VPN is running and then after you stop it:
resolvectl dns resolvectl domain
Thank you!
On Wed Sep27'23 03:04:53PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Wed, 27 Sep 2023 15:04:53 -0700 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 9/27/23 09:14, Ranjan Maitra wrote:
From the past week, I have had an issue in that after several hours, some particular sites become inaccessible to me, and can only be accessed if I use restart using sudo systemctl restart systemd-resolved.service
What particular issues cause this? Why did it start a week ago, and has become quite reliable in its annoyance? (I have to say that when I can no longer access this site, I am no longer on Cisco SecureClient VPN, which is also one of the sites which can not be accessed with Cisco SecureClient VPN without restarting systemd-resolved.service, and the site is my worksite domain).
That is probably relevant. resolved supports split DNS when using a VPN.
I think so too!
Try the following commands both while the VPN is running and then after you stop it:
resolvectl dns resolvectl domain
while running:
$ resolvectl dns Global: [IP addresses associated with my VPN site] {*} Link 2 (enp57s0u2u1u1): [IP addresses associated with my ISP] 192.168.1.1 {**} Link 22 (cscotun0):
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP] Link 22 (cscotun0):
where [VPN connection] stands for the address that is associated with VPN.
After stopping VPN:
$ resolvectl dns Global: [Same as {*}] Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP]
After $ sudo systemctl restart systemd-resolved.service
$ resolvectl dns Global: Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: Link 2 (enp57s0u2u1u1): [ISP]
Seems to me there is something "sticky" about the VPN connection?
Many thanks for your suggestions and help!
Best wishes, Ranjan
On 9/28/23 05:02, Ranjan Maitra wrote:
$ resolvectl dns Global: [IP addresses associated with my VPN site] {*} Link 2 (enp57s0u2u1u1): [IP addresses associated with my ISP] 192.168.1.1 {**} Link 22 (cscotun0):
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP] Link 22 (cscotun0):
where [VPN connection] stands for the address that is associated with VPN.
After stopping VPN:
$ resolvectl dns Global: [Same as {*}] Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP]
After $ sudo systemctl restart systemd-resolved.service
$ resolvectl dns Global: Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: Link 2 (enp57s0u2u1u1): [ISP]
Seems to me there is something "sticky" about the VPN connection?
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Thu, 28 Sep 2023 10:32:55 -0700 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 9/28/23 05:02, Ranjan Maitra wrote:
$ resolvectl dns Global: [IP addresses associated with my VPN site] {*} Link 2 (enp57s0u2u1u1): [IP addresses associated with my ISP] 192.168.1.1 {**} Link 22 (cscotun0):
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP] Link 22 (cscotun0):
where [VPN connection] stands for the address that is associated with VPN.
After stopping VPN:
$ resolvectl dns Global: [Same as {*}] Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP]
After $ sudo systemctl restart systemd-resolved.service
$ resolvectl dns Global: Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: Link 2 (enp57s0u2u1u1): [ISP]
Seems to me there is something "sticky" about the VPN connection?
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Thanks, so what changed in the last week? Is it at the VPN end? I don't see an update of my client (Cisco SecureClient).
Best wishes, Ranjan
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Thu, 28 Sep 2023 10:32:55 -0700 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 9/28/23 05:02, Ranjan Maitra wrote:
$ resolvectl dns Global: [IP addresses associated with my VPN site] {*} Link 2 (enp57s0u2u1u1): [IP addresses associated with my ISP] 192.168.1.1 {**} Link 22 (cscotun0):
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP] Link 22 (cscotun0):
where [VPN connection] stands for the address that is associated with VPN.
After stopping VPN:
$ resolvectl dns Global: [Same as {*}] Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: [VPN connection domainname] [ISP] Link 2 (enp57s0u2u1u1): [ISP]
After $ sudo systemctl restart systemd-resolved.service
$ resolvectl dns Global: Link 2 (enp57s0u2u1u1): [Same as {**}]
$ resolvectl domain Global: Link 2 (enp57s0u2u1u1): [ISP]
Seems to me there is something "sticky" about the VPN connection?
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
Best wishes, Ranjan
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On 9/28/23 19:03, Ranjan Maitra wrote:
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
I don't know why it would have changed recently and I also don't have anything on the global setting.
My script has: resolvectl dns tun0 <vpn dns ip> resolvectl default-route tun0 false resolvectl domain tun0 <domains to resolve on vpn>
You probably need something more to remove the global settings as well.
Thanks!
On 9/28/23 19:03, Ranjan Maitra wrote:
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
I don't know why it would have changed recently and I also don't have anything on the global setting.
My script has: resolvectl dns tun0 <vpn dns ip> resolvectl default-route tun0 false resolvectl domain tun0 <domains to resolve on vpn>
You probably need something more to remove the global settings as well.
Is this a bug that should be reported? Against what? The reason I hesitate is because Cisco SecureClient VPN (a closed source proprietary application) is involved.
Best wishes, Ranjan
On 9/29/23 20:58, Ranjan Maitra wrote:
Thanks!
On 9/28/23 19:03, Ranjan Maitra wrote:
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
I don't know why it would have changed recently and I also don't have anything on the global setting.
My script has: resolvectl dns tun0 <vpn dns ip> resolvectl default-route tun0 false resolvectl domain tun0 <domains to resolve on vpn>
You probably need something more to remove the global settings as well.
Is this a bug that should be reported? Against what? The reason I hesitate is because Cisco SecureClient VPN (a closed source proprietary application) is involved.
And that's the only thing that could be doing it, so I don't think there's much point in filing a bug. I'm curious how it's doing that though.
On Fri Sep29'23 11:44:08PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Fri, 29 Sep 2023 23:44:08 -0700 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 9/29/23 20:58, Ranjan Maitra wrote:
Thanks!
On 9/28/23 19:03, Ranjan Maitra wrote:
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
I don't know why it would have changed recently and I also don't have anything on the global setting.
My script has: resolvectl dns tun0 <vpn dns ip> resolvectl default-route tun0 false resolvectl domain tun0 <domains to resolve on vpn>
You probably need something more to remove the global settings as well.
Is this a bug that should be reported? Against what? The reason I hesitate is because Cisco SecureClient VPN (a closed source proprietary application) is involved.
And that's the only thing that could be doing it, so I don't think there's much point in filing a bug. I'm curious how it's doing that though.
Right, I have been busy these past few days, but perhaps I should go and see what got upgraded. Cisco SecureClient has not got upgraded so must be something in Fedora.
Best wishes, Ranjan
users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Fri Sep29'23 11:44:08PM, Samuel Sieb wrote:
From: Samuel Sieb samuel@sieb.net Date: Fri, 29 Sep 2023 23:44:08 -0700 To: users@lists.fedoraproject.org Reply-To: Community support for Fedora users users@lists.fedoraproject.org Subject: Re: F38: systemd-resolved.service oddity
On 9/29/23 20:58, Ranjan Maitra wrote:
Thanks!
On 9/28/23 19:03, Ranjan Maitra wrote:
On Thu Sep28'23 10:32:55AM, Samuel Sieb wrote:
The problem is that the VPN is setting its options on the global state instead of the tunnel where they should be. Normally, when the tunnel goes away, so do the special settings for it, but here they're global, so they don't. I use a VPN at work and I have a little script that I run after connecting that sets the options for me.
Btw, can I know more about this script? Though it would be nice not to have to run anything as it just a week ago.
I don't know why it would have changed recently and I also don't have anything on the global setting.
My script has: resolvectl dns tun0 <vpn dns ip> resolvectl default-route tun0 false resolvectl domain tun0 <domains to resolve on vpn>
You probably need something more to remove the global settings as well.
Is this a bug that should be reported? Against what? The reason I hesitate is because Cisco SecureClient VPN (a closed source proprietary application) is involved.
And that's the only thing that could be doing it, so I don't think there's much point in filing a bug. I'm curious how it's doing that though.
As an update, some update to Fedora packages appears to have addressed this issue for about a bit more than the past couple of weeks. There has been no update to Cisco SecureClient in the meantime, so it appears that the issue must have been some update to some Fedora package which seems to have been fixed at least for now.
As reported in an earlier separate thread, the glibc issue with updated versions continues to not make Cisco SecureClient work at all, though. Downdating to glibc-2.37-1 is the only way to get SecureClient to work.
Best wishes, Ranjan
-
Joe Zeff -
Ranjan Maitra -
Samuel Sieb