Connections time out after disconnecting from Cisco Anyconnect vpn

I have an issue with Cisco AnyConnect Secure Mobility Client Version 4.10.08029.
Browsing before and during the vpn connection works just fine.
After I disconnect from VPN webpages take very long to load and ultimately time out.
A restart solves the problem, but this is cumbersome of course.
I would like to understand what is going on here, and ideally find a way to resume internet usage after a vpn session without rebooting.

Observations:

  1. The wifi indicator in the upper right corner has a question mark on it:
    Screenshot from 2024-04-22 19-55-19

  2. ping 8.8.8.8 works just fine

$ ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=115 time=101 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=115 time=143 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=115 time=89.9 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=115 time=30.1 ms
...
  1. Calling https://www.google.com/ gives

Hmm. We’re having trouble finding that site.
We can’t connect to the server at www.google.com.

  1. Calling http://8.8.8.8/ gives

The connection has timed out
The server at 8.8.8.8 is taking too long to respond.

  1. Calling https://8.8.8.8 takes really long,
    seems to redirect to https://dns.google/
    and ultimately gives

Hmm. We’re having trouble finding that site.
We can’t connect to the server at dns.google.

Looking at the details of my connection in the settings displays an Excellent Signal Strength, just like before and during the VPN connection.

Check when the issue happens:

grep -e "^hosts:" /etc/nsswitch.conf
grep -v -e "^#" -e "^$" /etc/resolv.conf
systemctl status systemd-resolved.service
resolvectl --no-pager status
resolvectl --no-pager query example.org

Try reconnecting your main connection as a workaround.

Cisco’s AnnyConnect client is not known for integrating nicely in standard systems. (I tried hard to say it nicely …)
Apparantly, it messes up name resolving, most probably by rewriting /etc/resolv.conf which should be a link to /run/systemd/resolve/stub-resolv.conf on standard Fedora installs (which use systemd’s resolvd).

Have you tried connecting to your Cisco VPN with an open client instead (openconnect)? This works very well if it works at all - the latter depends on the type of Cisco endpoint. Worth trying, though.

1 Like

I executed the commands before connecting and after disconnecting.

The grep commands yield the same result before and after:

$ grep -e "^hosts:" /etc/nsswitch.conf
hosts:      files myhostname mdns4_minimal [NOTFOUND=return] resolve [!UNAVAIL=return] dns
$ grep -v -e "^#" -e "^$" /etc/resolv.conf
nameserver 127.0.0.53
options edns0 trust-ad
search .

For the systemctl command Memory and CPU are a little higher (7.0M, 2.628s) after

$ systemctl status systemd-resolved.service
â—Ź systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
    Drop-In: /usr/lib/systemd/system/service.d
             └─10-timeout-abort.conf
     Active: active (running) since Mon 2024-04-22 20:04:34 CEST; 24h ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 1023 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 36973)
     Memory: 6.5M
        CPU: 2.516s
     CGroup: /system.slice/systemd-resolved.service
             └─1023 /usr/lib/systemd/systemd-resolved
~~ before ~~~~~~~~~
Apr 23 01:26:42 my-pc systemd-resolved[1023]: Clock change detected. Flushing caches.
Apr 23 01:26:47 my-pc systemd-resolved[1023]: wlp6s0: Bus client set default route setting: yes
Apr 23 01:26:47 my-pc systemd-resolved[1023]: wlp6s0: Bus client set DNS server list to: xxx.yyy.0.1
Apr 23 01:26:48 my-pc systemd-resolved[1023]: wlp6s0: Bus client set DNS server list to: xxx.yyy.0.1, 2222:8888:7777:4444:11:1111:ffff:aaaa
Apr 23 01:27:05 my-pc systemd-resolved[1023]: wlp6s0: Bus client set default route setting: no
Apr 23 01:27:05 my-pc systemd-resolved[1023]: wlp6s0: Bus client reset DNS server list.
Apr 23 20:21:09 my-pc systemd-resolved[1023]: Clock change detected. Flushing caches.
Apr 23 20:21:13 my-pc systemd-resolved[1023]: wlp6s0: Bus client set default route setting: yes
Apr 23 20:21:13 my-pc systemd-resolved[1023]: wlp6s0: Bus client set DNS server list to: xxx.yyy.0.1
Apr 23 20:21:14 my-pc systemd-resolved[1023]: wlp6s0: Bus client set DNS server list to: xxx.yyy.0.1, 2222:8888:7777:4444:11:1111:ffff:aaaa
~~~~~~~~~~~~~~~~
Apr 23 20:46:41 my-pc systemd-resolved[1023]: Using degraded feature set UDP instead of TCP for DNS server xxx.yyy.2.43.
Apr 23 20:46:47 my-pc systemd-resolved[1023]: Using degraded feature set TCP instead of UDP for DNS server xxx.yyy.2.57.
Apr 23 20:46:57 my-pc systemd-resolved[1023]: Using degraded feature set TCP instead of UDP for DNS server xxx.yyy.2.43.
Apr 23 20:47:17 my-pc systemd-resolved[1023]: Using degraded feature set UDP instead of TCP for DNS server xxx.yyy.2.43.
Apr 23 20:47:23 my-pc systemd-resolved[1023]: Using degraded feature set UDP instead of TCP for DNS server xxx.yyy.2.57.
Apr 23 20:47:28 my-pc systemd-resolved[1023]: Using degraded feature set TCP instead of UDP for DNS server xxx.yyy.2.43.
Apr 23 20:47:38 my-pc systemd-resolved[1023]: Using degraded feature set TCP instead of UDP for DNS server xxx.yyy.2.57.
Apr 23 20:47:48 my-pc systemd-resolved[1023]: Using degraded feature set UDP instead of TCP for DNS server xxx.yyy.2.43.
Apr 23 20:47:53 my-pc systemd-resolved[1023]: Using degraded feature set UDP instead of TCP for DNS server xxx.yyy.2.57.
Apr 23 20:47:58 my-pc systemd-resolved[1023]: Using degraded feature set TCP instead of UDP for DNS server xxx.yyy.2.43.
~~ after ~~~~~~~~~

For the first resolvectl command my target net (“my-uni”) is still there after disconnecting, indicating that something didn’t get cleaned up:

$ resolvectl --no-pager status
Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub
~~~~~ only after ~~~~~~~
Current DNS Server: xxx.yyy.2.57
       DNS Servers: xxx.yyy.2.43 xxx.yyy.2.57
        DNS Domain: my-uni.de ~.
~~~~~ only after ~~~~~~~

Link 2 (enp3s0f0)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (wlp6s0)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6
         Protocols: +DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: xxx.yyy.0.1
       DNS Servers: xxx.yyy.0.1 2222:8888:7777:4444:11:1111:ffff:aaaa

Link 6 (enp7s0f4u1u3c2)
    Current Scopes: none
         Protocols: -DefaultRoute LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported

The second resolvectl command times out after disconnecting:

$ resolvectl --no-pager query example.org
~~~~ before ~~~
example.org: a.b.c.d                     -- link: wlp6s0
             2222:2222:222:cccc:6666:8888:aaaa:8888 -- link: wlp6s0

-- Information acquired via protocol DNS in 25.6ms.
-- Data is authenticated: no; Data was acquired via local or encrypted transport: no
-- Data from: network
~~~~ after ~~~~
example.org: resolve call failed: Connection timed out

I’m not sure I understand what you mean by “reconnecting your main connection”. Turning the wifi off and on again (in the top right corner of my screen) does not work.

Try this way:

sudo systemctl restart systemd-resolved.service

If the issue persists, there must be some leftovers in the runtime directories.

For the sake of completeness: in my case the file /run/systemd/resolve/stub-resolv.conf was not rewritten (and /etc/resolv.conf was not reassigned)

I gave openconnect a shot (thanks for the suggestion, good to know) but it failed with various messages, most recently with a timeout.

1 Like