Forticlient Problem in Fedora 33

FortiClient SSL VPN installed and connected successfully but not resolving domains! it seems the requests don’t go through the VPN!

server IP address could not be found.
DNS_PROBE_FINISHED_NXDOMAIN

even in terminal it’s not resolving domains

2 Likes

It should be similar to the following:
Systemd-resolved not querying DNS server set by openvpn

Post the output if the issue persists:

resolvectl dns
resolvectl domain 

See also:

1 Like

thanks for the useful link! the issue resolved by setting domain and dns through these commands:

resolvectl dns vpn 192.168.x.x
resolvectl domain vpn "example.net"

but how can I persist them, because they need to be run again when I’m restarting

1 Like

Assuming that example.net and its subdomains should be resolved by 192.168.x.x:

sudo nmcli connection modify id VPN_CON \
    ipv4.dns 192.168.x.x ipv4.dns-search ~example.net
1 Like

it doesn’t work, I used this command and it works to set:

sudo systemd-resolve -i vpn --set-dns=192.168.x.x --set-domain=example.net

but the problem is when I disconnecting VPN or restarting, the link has changed and the config is cleared

resolvectl domain
Global:
Link 2 (eno2):
Link 3 (wlo1): ~. lan
Link 4 (virbr0):
Link 5 (virbr0-nic):
Link 7 (vpn):
1 Like

Let’s verify your VPN connection settings:

PAGER= nmcli connection show id VPN_CON

connection.id: vpn
connection.uuid: fc9e9fdd-19b1-404d-bf4d-4bf5f0d65b2f
connection.stable-id: –
connection.type: tun
connection.interface-name: vpn
connection.autoconnect: no
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1603957424
connection.read-only: no
connection.permissions: –
connection.zone: –
connection.master: –
connection.slave-type: –
connection.autoconnect-slaves: -1 (default)
connection.secondaries: –
connection.gateway-ping-timeout: 0
connection.metered: unknown
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)
connection.wait-device-timeout: -1

Weird, it seems the change you made with sudo nmcli connection modify was not persistent. That is strange. I don’t know what’s going on here.

Guess: is it possible that you have some script deleting and recreating the VPN connection, instead of using the same configured connection? (That would be really weird, but if so, connection.uuid would be different each time.) How exactly do you connect to the VPN? Do you select it in the gnome-shell (or Plasma or whatever) GUI menu, or are you running some command line script each time you connect?

If using GNOME, just editing the settings for your VPN in System Settings ought to be enough to persist changes. Other desktops will have similar settings. But using nmcli should work too, and clearly that has failed.

If you have checked “use this connection only for resources on its own network” in VPN settings, then NetworkManager should already set a DNS domain corresponding to your VPN’s gateway address, although I see that hasn’t happened here.

2 Likes

I’m using the official FortiClient app in GNOME.
when I’m disconnecting the FortiClient, the vpn link will be removed from the Global list, next time it creates vpn again but with a new Link number, and the configuration which I set has removed!

Hm, you might want to create a bug report against that app directly. I guess it is creating and deleting NetworkManager profiles itself. If so, no amount of configuration outside the app is going to help. So I see three options: (a) fix that app (good luck? it’s probably proprietary?), (b) disable systemd-resolved, or © sudo dnf install NetworkManager-fortisslvpn-gnome and try creating your VPN connection in System Settings instead. If you let NetworkManager handle your VPN, you’ll not only have much better desktop integration, you definitely won’t experience this bug (because NetworkManager knows how to configure systemd-resolved properly), and for bonus points you’ll be able to make permanent modifications to the NetworkManager profile if needed.

So if you have good luck with that NetworkManager plugin, that would probably be much better than using a third-party application to configure your VPN. Otherwise, I’m going to recommend disabling systemd-resolved as there’s not much else you can do if you have a third-party VPN app creating and deleting broken NetworkManager profiles such that it’s impossible to permanently modify them. A bug report against the app is warranted regardless, because it clearly doesn’t know how to create NetworkManager profiles that are compatible with split DNS. That is surprising, because Ubuntu has been using systemd-resolved for four years now, so I would expect third-party developers to have figured it out, but Ubuntu is a little different in that it reads /etc/resolv.conf still. If your VPN app is touching /etc/resolv.conf directly, then it’s really broken, but that would still work in Ubuntu, which would explain why the developers didn’t notice for so long.

If you need to disable systemd-resolved (untested):

# systemctl stop systemd-resolved.service
# systemctl disable systemd-resolved.service
# rm /etc/resolv.conf
# systemctl restart NetworkManager.service

Hopefully that should be enough for NetworkManager to recreate a new /etc/resolv.conf for you that it will manage manually. And presumably your VPN app will edit it (which it should not do)? I’m not sure.

(Edit: This post heavily edited, because I hit enter too soon, when my original post here was only half-written. Oops.)

1 Like