Open peutch opened 9 months ago
But forgot to say that it works using a simple command line like: sudo openfortivpn <HIDDEN> -u <USER> -p <PASSWORD> --trusted-cert 718d0201f19e60a0822abbe210a705d0a76d8e7fc38ad51d9a1aeb68ffddb2e0
.
That's because openfortivpn 1.21 expects pppd ≥ 2.5.0 by default, but your version of Debian ships pppd 2.4.9 < 2.5.0. It shouldn't work from the command line either, unless you pass openfortivpn 1.21 the run-time option --pppd-accept-remote=0
.
You need to build openfortivpn ≥ 1.21 with ./configure --enable-legacy-pppd
for targets platforms with pppd < 2.5.0.
If you are using a Debian package, can you please point the maintainer to this post, so that the Debian packages can be fixed?
That's because openfortivpn 1.21 expects pppd ≥ 2.5.0 by default, but your version of Debian ships pppd 2.4.9 < 2.5.0. It shouldn't work from the command line either, unless you pass openfortivpn 1.21 the run-time option
--pppd-accept-remote=0
.
Regarding your comment, this is still strange that the command line worked for me. Could then the option --pppd-accept-remote=0
be somehow default?
You need to build openfortivpn ≥ 1.21 with
./configure --enable-legacy-pppd
for targets platforms with pppd < 2.5.0.If you are using a Debian package, can you please point the maintainer to this post, so that the Debian packages can be fixed?
Maintainer was informed and very reactive: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056235#27
Both thanks!
Could the output running the command line with the option -v
of openfortivpn (1.21.0-1, build without --enable-legacy-pppd) and ppp (2.4.9-1+1.1+b1) be interesting?
@peutch Thank you so much for spending the time (you and the maintainer) ironing things out on Debian. I must admit I am not happy with this breaking change I had to introduce, but I had no other alternative (such as runtime detection of the version of pppd) with the little time I can dedicate to openfortivpn.
Could the output running the command line with the option
-v
of openfortivpn (1.21.0-1, build without --enable-legacy-pppd) and ppp (2.4.9-1+1.1+b1) be interesting?
Do you mean openfortivpn should be modified, so that the output of -v
gives a brief glimpse of build-time options?
Regarding your comment, this is still strange that the command line worked for me. Could then the option
--pppd-accept-remote=0
be somehow default?
Do you perhaps have 2 versions of openfortivpn on your machine? In any case, to find which of --pppd-accept-remote=0
and --pppd-accept-remote=1
is the default, compare either of these options to the absence of --pppd-accept-remote
. The option =0
or =1
that behaves the same as no --pppd-accept-remote
option is the default one.
Regarding your comment, this is still strange that the command line worked for me. Could then the option
--pppd-accept-remote=0
be somehow default?Do you perhaps have 2 versions of openfortivpn on your machine? In any case, to find which of
--pppd-accept-remote=0
and--pppd-accept-remote=1
is the default, compare either of these options to the absence of--pppd-accept-remote
. The option=0
or=1
that behaves the same as no--pppd-accept-remote
option is the default one.
No I have only one openfortivpn version which is the one provided by the Debian package installed. I have currently the build 1.21.0-1 which works using direct command line but not through NetworkManager (whatever CLI, TUI or GNOME). I did not tried yet the new build 1.21.0-2. Could its build log useful to explain this duality? (https://buildd.debian.org/status/fetch.php?pkg=openfortivpn&arch=amd64&ver=1.21.0-1&stamp=1700366564&raw=1)
I understand openfortivpn without --pppd-accept-remote
works fine. However, does it also work fine with both --pppd-accept-remote=0
and --pppd-accept-remote=1
?
In the build log you refer to openfortivpn is configured without --enable-legacy-pppd
:
./configure --build=x86_64-linux-gnu --prefix=/usr --includedir=\${prefix}/include --mandir=\${prefix}/share/man --infodir=\${prefix}/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=\${prefix}/lib/x86_64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --with-pppd=/usr/sbin/pppd --enable-resolvconf --with-resolvconf=/sbin/resolvconf
Configururing openfortivpn without --enable-legacy-pppd
makes --pppd-accept-remote=1
the default. This is supposed to work with pppd ≥ 2.5.0 but is supposed to fail with pppd < 2.5.0. Now your version of 2.4.9-1+1.1+b1 of pppd appears to be slightly patched, as a result I don't know if it behaves like vanilla 2.4.9, like 2.5.0, or something different.
Hello!!
I am openfortivpn maintainer on Debian! I uploaded the new revision with the flag --enable-legacy-pppd, I hope it works fine with NetworkManager-fortisslvpn.
btw, It was strange for me too. Before upload the new version 1.21.0 I made many tests from command line, and its work fine. ( I don't use networkmanager-fortisslvpn.)
Please let me know if is necessary any more changes.
Regards!
I understand openfortivpn without
--pppd-accept-remote
works fine. However, does it also work fine with both--pppd-accept-remote=0
and--pppd-accept-remote=1
?
Surprisingly, it works in both cases.
@epsilon77 Thank you for looking into this issue. One thing you may help with, is remind me whether NetworkManager-fortisslvpn handles routing internally, or delegates routing to pppd, like DNS. I don't think pppd can handle that, but I haven't looked at routing issues for quite a long time.
@peutch If it works in both cases, so be it. That's different from what I have heard so far from users on other distributions. It may just mean that pppd 2.4.9-1+1.1+b1 on Debian is different from, and possibly better than pppd 2.4.9 or pppd 2.5.0 on other distributions. I really don't have the time to get to the bottom of this specific question right now. The only relevant difference I can see between openfortivpn 1.20.5 and 1.21.0 is the ipcp-accept-remote
thing. The only possible issue I can imagine is that pppd itself behaves differently with option ipcp-accept-remote
than without. Either this different behaviour is incorrect, or maybe it is correct but unexpected by NetworkManager-fortisslvpn. In the latter case, we might need to adapt NetworkManager-fortisslvpn. But we're not there yet, because I don't even know how pppd behaves differently with/without ipcp-accept-remote
. It would be interesting to compare pppd logs with/without ipcp-accept-remote
.
@epsilon77 Thanks for the new build 2.21.0-2, it works fine. @DimitriPapadopoulos, Many thanks for your help and patience.
Hi,
On a Debian Sid system, I am using NetworkManager to activate a VPN configuration and it works with 1.20.5 and not with 1.21.0. The command line generated by NetworkManager is:
/usr/bin/openfortivpn -c /var/lib/NetworkManager-fortisslvpn/4d48a71a-ce3f-4cae-a421-ce0f17a0369d.config --no-routes --no-dns --pppd-use-peerdns=1 <HIDDEN> --trusted-cert 718d0201f19e60a0822abbe210a705d0a76d8e7fc38ad51d9a1aeb68ffddb2e0 --pinentry /usr/libexec/nm-fortisslvpn-pinentry --pppd-plugin /usr/lib/pppd/2.4.9/nm-fortisslvpn-pppd-plugin.so
Any idea?
Thanks.
ps: that follows https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1056235