openfortivpn 1.14.1 not resolving DNS on fedora33 #824

slartibart70 · 2020-12-31T20:28:21Z

Hi,
i'm using openfortivpn 1.14.1 on fedora33, the vpn can be established, but i cannot reach any (remote) server by its DNS name. IP is working perfectly, but no name resolution.
Interestingly, the entries created by openforti in /etc/resolv.conf are taken into account by 'dig', for example, 'dig' can resolve the dns names to valid ip addresses.
But, ssh or a browser cannot.

I found something similar in a bugreport to sshuttle (see: sshuttle/sshuttle#554) which had exactly the same problems.
According to this bugreport, the problem is systemd and 'split DNS' support.
They also showed some workaround i have not tried (yet)

Could you please take a look at this?

slartibart70 · 2021-01-01T20:24:16Z

Hi all,
my current workaround is to disable the systemd-resolved by replacing the symlink of /etc/resolv.conf (which points to the stub /run/systemd/resolve/stub-resolv.conf) with a static file.
Now, systemd-resolved is not responsible any more and the 'traditional' way of adding search or nameserver entries to /etc/resolv.conf works again.

As i said, a workaround for the time being, but a proper solution would be nice (handled automatically by openfortivpn).

Btw, you added a commandline-option to 1.13.x called '--use-resolvconf='
The man page still references this option (also with a sample the config file) but it does not seem to be valid any more? (throwing error messages when using it)
Got it lost somewhere on the road to 1.14.x?
And, would it help in this case anyway?

slartibart70 · 2021-01-01T20:28:41Z

one more thing:
openfortivpn adds (see workaround above) nameserver and search entries to /etc/resolv.conf
BUT:
When closing openforitvpn, only the nameserver entries are removed,
the search entries stay put....
Smells like a bug?

DimitriPapadopoulos · 2021-01-02T08:22:33Z

Yes, most of these issues seem well known. Substantial work is required to adapt to the new routing/DNS backends (systemd) that have appeared in recent Linux distributions. Please send some information if you want us to have a look at this issue:
https://github.com/adrienverge/openfortivpn/wiki#user-content-reporting-issues

The --use-resolvconf= option does work, it is simply disabled by the Fedora Packager because the resolvconf that ships with systemd is broken:
https://src.fedoraproject.org/rpms/openfortivpn/blob/master/f/openfortivpn.spec#_28

slartibart70 · 2021-01-02T11:51:08Z

Just a question:
wouldn't it be sufficient to check for the destination of the symlink (/etc/resolv.conf)? (see also man systemd-resolved)
Depending on this, if we see that this is e.g. using the stub, then leave /etc/resolv.conf alone (don't add any entries) and just add some commands like this:
sudo systemd-resolve --interface ppp0 --set-dns 10.62.32.11 --set-domain company.net

I tried this with a single domain and it seems to work.
So maybe it's as easy as this with adding several of these commands like you do already when constructing the 'search' entry in /etc/resolv.conf?

DimitriPapadopoulos · 2021-01-02T14:06:49Z

Yes, that's the spirit - but using D-Bus calls instead of running executables. I'm still seeing it as substantial work. If you want to contribute have a look at #600.

DimitriPapadopoulos · 2021-01-03T21:05:02Z

If you send the contents of /etc/resolv.conf before/during/after VPN operation, we can try to infer what fails in your case.

slartibart70 · 2021-01-05T08:45:45Z

at the moment, i can only provide the things i wrote down when testing (will reproduce later)

Test1: /etc/resolv.conf is a static file
calling openfortivpn adds to this file

search
nameserver

entries as expected (a lot of search entries coming from the company, but only2 nameserver items, so i am still in the limit of 3 nameserver entries and my local router is one of them)
Result: works as expected

Test2: /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf
The default contents of /etc/resolv.conf are

nameserver 127.0.0.53
options edns0 trust-ad
search local

Starting openfortivpn, the same search and nameserver entries are added to the (now symlinked) /etc/resolv.conf file.
But, this does not seem to be valid anymore for systemd-resolved to pick up.
When checking with

systemd-resolve --status
    Global
        Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
    resolv.conf mode: stub                                                 

    Link 2 (enp0s31f6)
        Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6                                   
            Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
    Current DNS Server: 192.168.3.1                                                 
           DNS Servers: 192.168.3.1                                                 
            DNS Domain: local ~.                                                    

    Link 3 (tun1)
    Current Scopes: none                                                        
        Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

you can see that Link3 (tun1) does not have any information about nameservers or search-info (to complete non-fqdn domains with)
Result:
Browser or ssh cannot resolve DNS any more. But, going to the sites/servers by IP is possible, meaning the tunnel is running successfully.

I added

sudo systemd-resolve --interface ppp0 --set-dns 10.62.32.11 --set-domain company.net

to test for one domain and this was working ok for browser and ssh.
(i'm not sure what the proper syntax is to add multiple domains (aka search entries) or multiple nameservers (comma separated list? multiple calls?.... did not find any docs for this and did not test any further)

Does this help?

DimitriPapadopoulos · 2021-01-06T12:58:21Z

Test 1 is expected to work.

Test 2 is not supported, systemd will not take into account or even overwrite any changes by openfortivpn.

slartibart70 · 2021-01-06T13:03:30Z

well, yes... that was the reason for opening this bugticket initially...

Anything we can do right now for a workaround (besides manually hacking in lines like 'systemd-resolved....' for any search entry and namesever?
Or is the preferred solution (for now) simply to make /etc/resolv.conf a static file (not symlinked to the stub) and be happy again until openforti is reworked?

DimitriPapadopoulos · 2021-01-06T13:04:36Z

I suppose we can see this as a duplicate of #600.

On Fedora 33, I suggest using NewtorkManager-fortivpnssl. It does call openfortivpn to create the tunnel but lets NetworkManager handle routing/DNS, and NetworkManager should in turn should call systemd.

slartibart70 · 2021-01-06T13:06:35Z

i see... ok, let's try this. I'll keep you updated :-)

slartibart70 · 2021-01-09T23:35:44Z

Hi,
i made some tests with plasma-nm-fortisslvpn and NetworkManager-fortisslvpn installed.
First impressions... not working as it should

What works:

Global
         Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
  resolv.conf mode: stub                                                 
Current DNS Server: 192.168.3.1                                          
       DNS Servers: 192.168.3.1                                          
        DNS Domain: local                                                

Link 2 (enp0s31f6)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6                                   
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.3.1                                                 
       DNS Servers: 192.168.3.1                                                 
        DNS Domain: local  

Link 5 (ppp0)
    Current Scopes: DNS LLMNR/IPv4                                              
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 10.62.32.11                                                 
       DNS Servers: 10.62.32.11 10.62.32.12

The nameservers are setup correctly.

The complete search path (which is pasted into the /etc/resolc.conf - stub/symlink (obviously without affecting systemd-resolvd) is not taken into account by networkmanager.
So i copied and pasted the search-line manually into the NM-forti ipv4/search domains form
After this, some name resolution (with short names) are resolved properly ex. vm1234 gets an answer from dig being expanded to vm1234.company.net

But: chrome browser still has problems opening company-websites which seem to make use of redirects (assumption! there is a central identity provider in place which intercepts the request to internal websites for login and redirects afterwards to the target site)

And:
se-linux is complaining about missing dac-override capability and being not allowed to getattr/read/open my ~/.ssh/certificates file for the ca-certificates.
A remedy for this was to set selinux to 'permissive' (testing only, i did not want to create rules yet)

Compared to using the static file (etc/resolv.conf), well, the NM approach is not working successfully and still seems to have problems interacting with the forti-server info and the systemd-resolvd
(the search info is pushed by the forti-server, maybe other things as well)

My conclusion: use the static /etc/resolv.conf approach for now, start openfortivpn manually on commandline (as i did already in fedora32) and all is working as expected

Any help on this?

DimitriPapadopoulos · 2021-01-11T09:13:30Z

I won't really have time to help with NetworkManager-fortivpnssl. Yet I believe it's the best way to handle machines based on NetworkManager. But then openfortivpn does not handle split DNS, which means NetworkManager-fortivpnssl cannot handle it either for now - the split-DNS parameters are not passed by openfortivpn to NetworkManager-fortivpnssl. That I can try to fix. It would help if I could see the (sanitized) output of openfortivpn -v -v, especially the parameters sent by the FortiGate in XML format.

Not sure about the difference between dig and Google Chrome. Anything in the system logs or in the Google Chrome logs?

I don't know about SELinux, it's always a pain to get things to work. You should probably open a bug report against Fedora, based on the instructions found in the system log file.

slartibart70 · 2021-01-11T11:18:52Z

I have put the fortivpn log here (sanitized, hopefully :-)
https://cust-owncloud.k-net.fr/s/7EWWrjqjK9NL4Sq

selinux: i could define rules myself, seems reasonable because the service needs access to my local (home-dir) files/certificates. dac-override could be bugworthy?

DimitriPapadopoulos · 2021-01-11T13:23:23Z

This a rather complex split-tunnel configuration, with many entries, but I don't see why it shouldn't work:

<ipv4>
    <dns domain='city.ads.xxxxx.me;ads.xxxxx.me;eil.xxxxx.me;xxxxx.me;rzcity.ads.xxxxx.me;brandxxx.ads.xxxxx.me;xxnyfs.ads.xxxxx.me;    -xxxxxxxxx.com;dc.company.local;company-aut.xxxx.biz;res.xxnyxxx.travel;xxnyxxx.travel;xxx.emea.local;arce.xxxxx.me;xxnytm.local' />
    <dns ip='10.62.32.11' />
    <dns ip='10.62.32.12' />
    <assigned-addr ipv4='10.147.42.246' />
    <split-tunnel-info>
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.0' mask='255.255.254.0' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.0' mask='255.255.255.0' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='10.0.0.0' mask='255.0.0.0' />
        <addr ip='xxx.0.0.0' mask='254.0.0.0' />
        <addr ip='192.168.0.0' mask='255.255.0.0' />
        <addr ip='172.16.0.0' mask='255.240.0.0' />
        <addr ip='xxx.xxx.xxx.0' mask='255.255.255.0' />
        <addr ip='xxx.xxx.xxx.0' mask='255.255.255.0' />
        <addr ip='xxx.xxx.xxx.0' mask='255.255.255.0' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='xxx.xxx.xxx.xxx' mask='255.255.255.255' />
        <addr ip='10.147.0.0' mask='255.255.252.0' />
        <addr ip='10.147.32.0' mask='255.255.240.0' />
        <addr ip='10.147.128.0' mask='255.255.192.0' />
    </split-tunnel-info>
</ipv4>

No split-DNS here, the DNS part looks pretty simple, just the two DNS servers 10.62.32.11 and 10.62.32.12 taking over. This is a very common DNS configuration. We do have this split-tunnel complex configuration though, so it might be a routing issue. Do the above complex routing instructions appear in the system IPv4 routing configuration after starting openfortivpn? I want to make sure this is not a routing issue.

Ah, I think I've got it, you have way too many search domains:
resolv.conf limited to six domains with a total of 256 characters
Ir looks like /etc/resolv.conf cannot handle the very complex DNS configuration at your place.

DimitriPapadopoulos · 2021-01-11T13:34:38Z

You could verify the above by trying to resolve a name in some of the first 6 domains and then in some of the other domains.

slartibart70 · 2021-01-11T13:34:45Z

Thanks for the analysis.
Yes, there are a lot of search domains (not my fault, btw :-) . When you talk of "/etc/resolv.conf cannot handle this"... did you mean the static file or the symlinked one?
With the static file (my workaround) all is working as expected i don't see a limitation in search behaviour?
And when putting all the search data into the network-manager forti-form while using the symlinked(stub) resolv.conf maybe here we get a limitation?

DimitriPapadopoulos · 2021-01-11T13:44:42Z

I don't know. It looks like the limitation has been somehow removed in recent versions of RedHat or glibc 2.26:
https://access.redhat.com/solutions/58028
Unfortunately it looks individual pieces of software may still fail, depending on the way they handle DNS queries.

DimitriPapadopoulos · 2021-01-11T13:45:50Z

So the limitation is not with the /etc/resolv.conf file itself (of course) but with the different pieces of software that read this file, either directly or through other pieces of software.

jchmielniak · 2021-01-21T13:26:39Z

Hi,
i can confirm the same problem with F33.
I use split dns and can provide logging if it helps.

Log for XML Connection:

<?xml version='1.0' encoding='utf-8'?>
<sslvpn-tunnel ver='2' dtls='1' patch='1'>
  <dtls-config heartbeat-interval='10' heartbeat-fail-count='10' heartbeat-idle-timeout='10' client-hello-timeout='10'/>
  <tunnel-method value='ppp'/>
  <tunnel-method value='tun'/>
  <fos platform='FG1K5D' major='6' minor='02' patch='2' build='1010' branch='1010'/>
  <auth-ses check-src-ip='1' tun-connect-without-reauth='0' tun-user-ses-timeout='30'/>
  <client-config save-password='on' keep-alive='on' auto-connect='off'/>
  <ipv4>
    <split-dns domains='hmmrz.lan,hmm.lan,zhp.lan' dnsserver1='10.10.4.205' dnsserver2='10.10.4.202'/>
    <assigned-addr ipv4='10.10.220.1'/>
    <split-tunnel-info>
      <addr ip='192.168.0.0' mask='255.255.0.0'/>
      <addr ip='10.10.0.0' mask='255.255.0.0'/>
      <addr ip='10.9.2.0' mask='255.255.255.0'/>
    </split-tunnel-info>
  </ipv4>
  <idle-timeout val='3600'/>
  <auth-timeout val='28800'/>
</sslvpn-tunnel>

I have to run manually resolvectl to set dns and domain for ppp0. Log was made with openfortivpn, but I use NetworkManager with Automatic DNS and 'use this connection for ressources on this network'

Jacek

marco-santamaria · 2021-02-04T15:02:59Z

Same problem here with F33 and openfortivpn 1.14.1

DimitriPapadopoulos · 2021-02-04T15:40:50Z

Unfortunately openfortivpn requires substantial changes to fully adapt to the most recent distributions that rely on systemd-resolved such as Fedora 33. By "substantial", I mean beyond my current capacity to contribute.
Yet NetworkManager-fortivpnssl is supposed to work. I suggest you use it instead of directly running openfortivpn on Fedora 33. If NetworkManager-fortivpnssl does not work for you, please open a ticket against NetworkManager-fortivpnssl.
We're still interested in getting reports of course; it will help qualify the problem and improve openfortivpn whenever someone is able to contribute. For pure DNS issues, the following would help :
1. Show the contents of /etc/resolv.conf before/after the VPN connection.
2. Show the output of resolvectl status and/or nmcli device show before/after the VPN connection.
3. Give an example of the DNS issues you're experiencing, such as the output of the systemd-resolve my.server / systemd-resolve query my.server command and the more traditional nslookup my.server command.
4. Run openfortivpn -v -v and paste at least the XML configuration sent by the FortiGate.
5. Test different options related to DNS, typically --use-resolvconf=0 vs. --use-resolvconf=1.

marco-santamaria · 2021-02-08T14:16:12Z

The issue I have is only DNS related, as the tunnel is up and running and I can reach the server using the IP address.

i. My /etc/resolv.conf looks like this before the VPN connection

nameserver 127.0.0.53
options edns0 trust-ad

After the connection there are two additional IPs at the top of the file

ii. The output of resolvectl status looks something like this before the VPN connection

Global
       Protocols: LLMNR=resolve -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub                                                 

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

Link 3 (wlp0s20f3)
    Current Scopes: DNS LLMNR/IPv4 LLMNR/IPv6                                   
         Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 8.8.8.8                                                     
       DNS Servers: 8.8.8.8                                                     
        DNS Domain: ~.                                                          

Link 4 (virbr0)
Current Scopes: none                                                        
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 5 (virbr0-nic)
Current Scopes: none                                                        
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

After the VPN connection the following item is added

Link 7 (ppp0)
Current Scopes: LLMNR/IPv4                                                  
     Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

iii . The output of systemd-resolve says always resolve call failed: 'xxxxxx.xxxx.xx' not found, but nslookup is resolving the domain name correctly.

iv. The only XML code that I can spot in the openfortivpn verbose output looks something like the following

<?xml version='1.0' encoding='utf-8'?>
<sslvpn-tunnel ver='2' dtls='1' patch='1'>
  <dtls-config heartbeat-interval='10' heartbeat-fail-count='10' heartbeat-idle-timeout='10' client-hello-timeout='10' />
  <tunnel-method value='ppp' />
  <tunnel-method value='tun' />
  <fos platform='FG1K2D' major='6' minor='00' patch='11' build='0387' branch='0387' />
  <client-config save-password='off' keep-alive='off' auto-connect='off' />
  <ipv4>
    <dns ip='x.x.x.x' />
    <dns ip='y.y.y.y' />
    <assigned-addr ipv4='z.z.z.z' />
    <split-tunnel-info>
      <addr ip='w.w.w.w' mask='255.255.255.255' />
      ...
    </split-tunnel-info>
  </ipv4>
  <idle-timeout val='3600' />
  <auth-timeout val='28800' />
</sslvpn-tunnel>

where the two dns ip items contain the same IPs that have been added in /etc/resolv.conf

v. In my system the option use-resolvconf is not available, therefore I cannot test it.

Cheers

DimitriPapadopoulos · 2021-02-08T18:44:15Z

i. File /etc/resolv.conf has been updated as expected. That's not ideal, but that's how it is for now.

ii. The PPP tunnel has been added. Unfortunately we cannot associate the new DNS servers to the tunnel, for lack of systemd-resolved support.

iii. That's to be expected: systemd-resolve queries systemd-resolved which does not take into account the changes in /etc/resolv.conf, while nslookup uses the legacy DNS mechanism that does take into account /etc/resolv.conf. It all depends on the DNS client mechanism used by your software.

iv. Yes, you do get the DNS server addresses here <dns ip='x.x.x.x' /><dns ip='y.y.y.y' />. It makes sense since /etc/resolv.conf has been updated.

v. Ah right, that option has been disabled on Fedora because it doesn't work well - or rather used not to work on Fedora 32 but might work on Fedora 33. You may want to compile openfortivpn and check if it works better with --use-resolvconf. If it works, we'll modify the Fedora 33 packages.

I understand nslookup does work in your case. Which piece of software doesn't work?

marco-santamaria · 2021-02-09T14:20:37Z

v. Ah right, that option has been disabled on Fedora because it doesn't work well - or rather used not to work on Fedora 32 but might work on Fedora 33. You may want to compile openfortivpn and check if it works better with --use-resolvconf. If it works, we'll modify the Fedora 33 packages.

I'll try and I'll report here the result

I understand nslookup does work in your case. Which piece of software doesn't work?

ssh and git are not working. Currently I am adding the IPs in /etc/hosts to make them work, as NetworkManager-fortivpnssl is supporting 2FA via SMS, but is not working for me right now (check here)

emelenas · 2021-02-14T18:06:34Z

I ran into the same issue, also on a Fedora 33. I have compiled openfortivpn and the option --use-resolvconf works as expected, setting the DNS servers and domain search, for me at least.

NetworkManager-fortisslvpn does not read the https response, what it does is use the info sent by pppd. See https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/36 and https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/33

DimitriPapadopoulos · 2021-02-15T10:05:58Z

@emelenas I see, the short term solution for fedora is to reenable --use-resolvconf in fedora packages, starting with Fedora 33.

The long term solution remains to:

fix NetworkManager-fortisslvpn,
add Network-Manager and systemd-resolved support.

Chimped config containing these settings from adrienverge/openfortivpn#824 (comment). This doesn't actually *do* anything with the settings yet. See dlenski/openconnect#151 and https://gitlab.com/openconnect/openconnect/-/merge_requests/132 for discussion about split-DNS. Signed-off-by: Daniel Lenski <[email protected]>

priiduneemre · 2022-02-15T05:57:18Z

@emelenas I see, the short term solution for fedora is to reenable --use-resolvconf in fedora packages, starting with Fedora 33.

The long term solution remains to:
* fix _NetworkManager-fortisslvpn_,

* add Network-Manager and _systemd-resolved_ support.

Is it possible that the --use-resolvconf option was disabled again in packages built for Fedora 35? The workaround seems to work fine with the 1.17.0-2.fc34 package (thank god), but basically says no such option when using 1.17.0-2.fc35.

Had to revert to the F34 one by force to get around this issue.

DimitriPapadopoulos · 2022-02-15T06:16:46Z

Why disable --use-resolvconf?

priiduneemre · 2022-02-15T06:45:17Z

Sorry for the ambiguous wording. I was asking whether it HAS BEEN disabled again (by accident? on purpose?).

The point was that the F35 package for 1.17.0-2 doesn't recognize the --use-resolveconf option anymore, while the one for F34 still does. Thus, the workaround is intact for F34, but not for F35 (as far as I can tell).

akellar · 2022-02-18T16:24:03Z

Also tried using --use-resolvconf and it does not appear to work. Trying to test NetworkManager-FortiSslVpn

DimitriPapadopoulos · 2022-02-18T16:47:34Z

What do you mean by "it does not appear to work"? What is the error message? Which exact Linux distribution?

akellar · 2022-02-18T16:57:42Z

I am running Fedora 35. NetworkManager-FortiSslVpn will establish the connection, route privately, but then not route publicly. We use split-tunneling and split-dns and I'm wondering if NetworkManager needs additional configuration. I'll try to investigate that as well unless you have any experience with it.

At any rate, back to openfortivpn. This is what I see when using my configuration file:

[user@computer-fedora ~]$ sudo openfortivpn -c /etc/openfortivpn/config
WARN: Ignoring option "use-resolvconf".
INFO: Connected to gateway.
INFO: Authenticated.
INFO: Remote gateway has allocated a VPN.
Using interface ppp0
Connect: ppp0 <--> /dev/pts/0
INFO: Got addresses: [x.x.x.x], ns [x.x.x.x], ns_suffix [domain.com]
INFO: Negotiation complete.
INFO: Got addresses: [x.x.x.x], ns [x.x.x.x], ns_suffix [domain.com]
INFO: Negotiation complete.
INFO: Negotiation complete.
local IP address x.x.x.x
remote IP address x.x.x.x
INFO: Interface ppp0 is UP.
INFO: Setting new routes...
INFO: Adding VPN nameservers...
INFO: Tunnel is up and running.

This is what I see if I try to call it inline:
sudo openfortivpn --use-resolvconf -c /etc/openfortivpn/config
openfortivpn: unrecognized option '--use-resolvconf'
Usage: openfortivpn [[:]] [-u ] [-p ]
[--otp=] [--otp-delay=] [--otp-prompt=]
[--pinentry=] [--realm=]
[--ifname=] [--set-routes=<0|1>]
[--half-internet-routes=<0|1>] [--set-dns=<0|1>]
[--pppd-use-peerdns=<0|1>] [--pppd-log=]
[--pppd-ifname=] [--pppd-ipparam=]
[--pppd-call=] [--pppd-plugin=]
[--ca-file=]
[--user-cert=] [--user-key=]
[--use-syslog] [--trusted-cert=]
[--persistent=] [-c ] [-v|-q]
openfortivpn --help
openfortivpn --version

priiduneemre · 2022-02-25T06:41:31Z

@akellar: Try installing openfortivpn-1.17.0-2.fc34 (i.e. the latest version of the same package for Fedora 34, not 35). See if --use-resolvconf works there.

DimitriPapadopoulos · 2022-02-25T08:20:03Z

Indeed, openfortivpn-1.17.0-2.fc34 had been released on 21 August 2021 and was supposed to have re-enabled resolvconf support.
https://src.fedoraproject.org/rpms/openfortivpn/c/e18bf25eec9db844634286252acd46d78266a6bf?branch=f34

DimitriPapadopoulos · 2022-02-25T08:30:29Z

Unfortunately, it looks like the bug has not really been fixed. Please follow up in #957. This bug report was about Fedora 33 which is EOL'ed.

DimitriPapadopoulos added the duplicate label Jan 6, 2021

gustav87 mentioned this issue Mar 31, 2021

openfortivpn 1.16.0 DNS problems #881

Open

DimitriPapadopoulos closed this as completed Feb 25, 2022

openfortivpn 1.14.1 not resolving DNS on fedora33 #824

openfortivpn 1.14.1 not resolving DNS on fedora33 #824

Comments

slartibart70 commented Dec 31, 2020

slartibart70 commented Jan 1, 2021

slartibart70 commented Jan 1, 2021

DimitriPapadopoulos commented Jan 2, 2021 • edited Loading

slartibart70 commented Jan 2, 2021

DimitriPapadopoulos commented Jan 2, 2021

DimitriPapadopoulos commented Jan 3, 2021

slartibart70 commented Jan 5, 2021

DimitriPapadopoulos commented Jan 6, 2021

slartibart70 commented Jan 6, 2021

DimitriPapadopoulos commented Jan 6, 2021 • edited Loading

slartibart70 commented Jan 6, 2021

slartibart70 commented Jan 9, 2021 • edited Loading

DimitriPapadopoulos commented Jan 11, 2021

slartibart70 commented Jan 11, 2021

DimitriPapadopoulos commented Jan 11, 2021

DimitriPapadopoulos commented Jan 11, 2021

slartibart70 commented Jan 11, 2021

DimitriPapadopoulos commented Jan 11, 2021

DimitriPapadopoulos commented Jan 11, 2021 • edited Loading

jchmielniak commented Jan 21, 2021 • edited by DimitriPapadopoulos Loading

marco-santamaria commented Feb 4, 2021

DimitriPapadopoulos commented Feb 4, 2021 • edited Loading

marco-santamaria commented Feb 8, 2021 • edited Loading

DimitriPapadopoulos commented Feb 8, 2021 • edited Loading

marco-santamaria commented Feb 9, 2021 • edited Loading

emelenas commented Feb 14, 2021

DimitriPapadopoulos commented Feb 15, 2021

priiduneemre commented Feb 15, 2022 • edited Loading

DimitriPapadopoulos commented Feb 15, 2022

priiduneemre commented Feb 15, 2022 • edited Loading

akellar commented Feb 18, 2022 • edited Loading

DimitriPapadopoulos commented Feb 18, 2022 • edited Loading

akellar commented Feb 18, 2022 • edited Loading

priiduneemre commented Feb 25, 2022 • edited Loading

DimitriPapadopoulos commented Feb 25, 2022

DimitriPapadopoulos commented Feb 25, 2022

DimitriPapadopoulos commented Jan 2, 2021 •

edited

Loading

DimitriPapadopoulos commented Jan 6, 2021 •

edited

Loading

slartibart70 commented Jan 9, 2021 •

edited

Loading

DimitriPapadopoulos commented Jan 11, 2021 •

edited

Loading

jchmielniak commented Jan 21, 2021 •

edited by DimitriPapadopoulos

Loading

DimitriPapadopoulos commented Feb 4, 2021 •

edited

Loading

marco-santamaria commented Feb 8, 2021 •

edited

Loading

DimitriPapadopoulos commented Feb 8, 2021 •

edited

Loading

marco-santamaria commented Feb 9, 2021 •

edited

Loading

priiduneemre commented Feb 15, 2022 •

edited

Loading

priiduneemre commented Feb 15, 2022 •

edited

Loading

akellar commented Feb 18, 2022 •

edited

Loading

DimitriPapadopoulos commented Feb 18, 2022 •

edited

Loading

akellar commented Feb 18, 2022 •

edited

Loading

priiduneemre commented Feb 25, 2022 •

edited

Loading