Update the diagnostics when the VPN is connected:
https://discussion.fedoraproject.org/t/cannot-connect-to-computers-over-anyconnect-vpn-with-fedora-33/71208/19?u=vgaetera
And resolve the target domain with public and VPN resolvers:
nslookup target.domain 8.8.8.8
nslookup target.domain vpn.resolver.ip.address
Your VPN resolver should be something in the 192.168.70.0/23 subnet.
Here’s some of the information. Unfortunately, I cannot figure out what the VPN resolver address in 192.168.70.0/23 subnet.
$ ip route show
0.0.0.0/1 via 192.168.0.1 dev enp4s0 proto static metric 100
default dev tun0 scope link
default via 192.168.0.1 dev enp4s0 proto dhcp metric 100
4.31.13.10 via 192.168.0.1 dev enp4s0 src 192.168.0.106
128.0.0.0/1 via 192.168.0.1 dev enp4s0 proto static metric 100
192.168.0.0/24 dev enp4s0 proto kernel scope link src 192.168.0.106 metric 100
192.168.70.0/23 dev tun0 scope link
192.168.222.0/24 dev virbr0 proto kernel scope link src 192.168.222.1 linkdown
$ ip route get (ip address)
(ip address) via 192.168.0.1 dev enp4s0 src 192.168.0.106 uid 1000
cache
$ nslookup work.com 8.8.8.8
Server: 8.8.8.8
Address: 8.8.8.8#53
Non-authoritative answer:
Name: work.com
Address: (ip address) <-- this is correct
Still trying to figure out the resolver in 192.168.70.0/23
The current runtime routing config looks fine, so let’s try to find resolvers:
DOMAIN="target.domain"; for IP in 192.168.{70..71}.{0..255}; \
do nslookup -timeout=1 ${DOMAIN} ${IP} &> /dev/null && echo ${IP}; done
In addition, check the OpenConnect service log, perhaps resolvers are pushed by the VPN server.
Here’s what I found:
$ nslookup work.com 192.168.70.xxx
;; connection timed out; no servers could be reached
Is this still valid?
Add static routes to those resolvers and query them directly:
sudo ip route add 192.168.100.1 dev tun0
sudo ip route add 192.168.110.5 dev tun0
nslookup target.domain 192.168.100.1
nslookup target.domain 192.168.110.5
No, since I moved away from Anyconnect and started using Openconnect it is now this
nameserver 127.0.0.53
options edns0 trust-ad
search work.com
These work fine. I expect them to since there has never been an issue finding the IP address from DNS.
I use cisco anyconnect v4.9.05042 to connect with work from my fc33 laptop and have no problem connecting and accessing restricted pages
Changing the version is out of my control. The IT department decides when updates are rolled out. Out of curiosity, can you try version 4.7.04056? If that doesn’t work for you, then I could have a reason to request testing 4.9.05042 or a newer version from my IT dept.
-Mike
To vgaetera, mcatanzaro, and others who took the time to help, thank you very much. After re-installing both Fedora 32 and still having the same problem, I finally arrived at a solution. In the end, it was not a network issue but a problem reading my certificate for the VPN.
For the past several years I had always used Mozilla Firefox to install the security certificate and it clearly worked. Sometime around 2/10-2/12 this method stopped working even for an already installed security certificate. Instead, I had to switch to an alternate method (provided by my IT dept) to install the security certificate and the problem was fixed.
Thanks again to all that helped me with this problem.
No, I don’t recommend that you use resolv.conf mode: foreign. That’s what’s causing your strange DNS server configuration, which includes both global and link-specific DNS servers. They’re both used for every search, and the one who finishes first wins, which isn’t what you want. To revert to default behaviour, make sure /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, as it is by default, and remove anything you added to NetworkManager.conf. Fixing your DNS configuration, however, will not solve your routing issue, which is a separate issue.
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.