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

3 Likes

It should be similar to the following:
https://discussion.fedoraproject.org/t/systemd-resolved-not-querying-dns-server-set-by-openvpn/74961/2?u=vgaetera

Post the output if the issue persists:

resolvectl dns
resolvectl domain 

See also:
https://fedoramagazine.org/systemd-resolved-introduction-to-split-dns/

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 (c) 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

I wish. Originally I was using sudo /usr/bin/openfortivpn -c with a configuration file specifying host, trusted-cert & username. I could connect to internal resources via IP address and could resolve via nslookup, but when loading a page in Chromium or Firefox it would timeout with ERR_CONNECTION_TIMED_OUT.

Server:		10.xxx.xxx.xxx
Address:	10.xxx.xxx.xxx#53

server.example.com	canonical name = server.inside.example.com.
Name:	server.inside.example.com
Address: 10.xxx.xxx.xxx

I installed the Gnome component and configured the VPN, but still could not connect to internal resources in FF or Chrome. From what I can tell, NetworkManager is still unable to recognize the connection settings:

[me@localhost ~]$ resolvectl domain
Global:
Link 2 (enp0s31f6):
Link 3 (wlp0s20f3): ~.
Link 4 (virbr0):
Link 5 (virbr0-nic):
Link 9 (ppp0):
[me@localhost ~]$ resolvectl dns
Global:
Link 2 (enp0s31f6):
Link 3 (wlp0s20f3): 8.8.8.8 8.8.4.4
Link 4 (virbr0):
Link 5 (virbr0-nic):
Link 9 (ppp0):

What I find really interesting is that I can load a page on my domain using the alternative browser, Midori.

It seems you have no DNS servers configured for your VPN interface. Normally I would expect DNS servers to be detected automatically, but oh well. You’re probably going to need to manually set some DNS servers in System Settings → Network → VPN → IPv4 and IPv6 tabs. Be sure to disconnect and reconnect the VPN once that’s done.

Next problem is ppp0 has no DNS domain set. Hopefully NetworkManager is just noticing that you have no DNS on ppp0 and falling back to wlp0s20f3 instead, and will hopefully fix that automatically once you configure some DNS servers for ppp0. But then again, maybe not. See here for hints on how this is supposed to work.

What I find really interesting is that I can load a page on my domain using the alternative browser, Midori.

That’s extremely strange. Midori uses WebKitGTK, which uses libsoup, which uses GResolver, which we maintain. It is not magic. Based on the configuration you posted, it should only be using Google public DNS, so it should be impossible for it to resolve internal domain names.

1 Like