This work fine in fedora 38 box, when I upgrade to fedora 39 box this module don´t work I installed the fedora 38 rpms packages on fedora 39 and It's work Reproducible: Always Steps to Reproduce: 1.From Gnome Desktop 2.Select to connect to VPN 3.Not work Actual Results: Doesn't connect to Fortinet VPN Expected Results: Connect to Fortinet VPN /var/log/messages: Oct 25 15:44:14 casa NetworkManager[13892]: Plugin /usr/lib64/pppd/2.5.0/nm-fortisslvpn-pppd-plugin.so loaded. Oct 25 15:44:14 casa kernel: PPP generic driver version 2.4.2 Oct 25 15:44:14 casa pppd[13892]: pppd 2.5.0 started by root, uid 0 Oct 25 15:44:14 casa pppd[13892]: Using interface ppp0 Oct 25 15:44:14 casa NetworkManager[13892]: Using interface ppp0 Oct 25 15:44:14 casa NetworkManager[13892]: Connect: ppp0 <--> /dev/pts/3 Oct 25 15:44:14 casa NetworkManager[13892]: {/tmp/.PWDJD2} {/tmp} Oct 25 15:44:14 casa NetworkManager[13892]: {/tmp/.PWDJD2} {.PWDJD2} Oct 25 15:44:14 casa pppd[13892]: Connect: ppp0 <--> /dev/pts/3 Oct 25 15:44:14 casa NetworkManager[914]: <info> [1698266654.2773] manager: (ppp0): new Ppp device (/org/freedesktop/NetworkManager/Devices/7) Oct 25 15:44:14 casa kernel: PPP BSD Compression module registered Oct 25 15:44:14 casa kernel: PPP Deflate Compression module registered Oct 25 15:44:14 casa NetworkManager[13888]: INFO: Got addresses: [10.200.200.6], ns [10.100.100.201, 10.101.101.201] Oct 25 15:44:14 casa NetworkManager[13888]: INFO: Negotiation complete. Oct 25 15:44:16 casa NetworkManager[13888]: INFO: Negotiation complete. Oct 25 15:44:16 casa NetworkManager[13892]: Peer refused to agree to his IP address Oct 25 15:44:16 casa NetworkManager[13892]: Connect time 0.1 minutes. Oct 25 15:44:16 casa NetworkManager[13892]: Sent 1137 bytes, received 1105 bytes. Oct 25 15:44:16 casa pppd[13892]: Peer refused to agree to his IP address Oct 25 15:44:16 casa pppd[13892]: Connect time 0.1 minutes. Oct 25 15:44:16 casa pppd[13892]: Sent 1137 bytes, received 1105 bytes.
ipcp-accept-remote in /etc/ppp/options does not help to mane NM initiated connection to work. As a workaround I am using openfortivpn from comamnd line, but this is not comfortable solution, it is really just a workaround and we definitely need to have working fortivpn connections initiated from NM. There is interesting comment here, maybe this could be the source of (compatibility, the new behavior is believed to be correct] problem.| https://github.com/ppp-project/ppp/issues/451 In both negotiations, the peers are unable to agree on an IP address, so in both cases ipcp-accept-remote is the right thing to use. The behaviour in this situation, when the peers don't agree, was changed by commit 9fe8923 ("pppd: Fix enforcing peer IP address (#235)", 2021-01-26), with the comments: pppd: Fix enforcing peer IP address (#235) If peer address is specified and ipcp-accept-remote is not set then peer address is enforced. But there is bug in pppd which allows peer to not use supplied address when it reply with empty IPCP ConfReq. In this case pppd thinks that peer accepted its idea of remote/peer address even it is not truth. So the new behaviour of failing to bring up the link when the two ends can't agree on an IP address and the ipcp-accept-remote option is not used is deliberate, and I think correct.
I'm having the same issue, I'm looking what we can do.
So what can be done. Just try this - works well for me: - open connection editor - click New - for connection type, select VPN, Fortinet SSL VPN (OpenConnect), which is another Fortinet SSL VPN implementation in NetworkManager - copy configuration data from your original Fortinet connection - save configuration - connect using the newly created Fortinet SSL VPN (OpenConnect) connection, you will be asked for username / password The above works for me with VPN client authenticated / authorized only by username / password, e.g. no certificates configured on client side. Please do not ask me why only username / password, this is how server is configured. I did not test with certificates on client side. Then, if you are person with red hat on your head, use this new (hopefully) working connection to resolve the problem this ticket is about.
Doh!! I've been using NetworkManager-fortisslvpn for years, I was not aware that OpenConnect would allow the same! It even works with TOTP tokens like in our company. The SELInux policy for NetworkManager-fortisslvpn is also broken, if you are using two factor authentication and try to save the password, the prompt for the OTP token is never shown because blocked by the policy. I will check if the NetworkManager-openconnect packages can obsolete the NetworkManager-fortisslvpn packages and we should be good to go.
If I can vote, my +1 for fixed NetworkManager-fortisslvpn and related selinux policy. IMHO it is frequently used and having one Fortinet SSL VPN implementation backed by another implementation has been found I would say very useful just now, right? :-) And the lastest openfortivpn works with the current ppp-2.5.0-3.fc39.x86_64, so fix for Fortinet SSL VPN looks like possible and RH also IMHO has enough people to fix selinux policy. :-)
After upgrading to Fedora 39 ppp changed and while openfortivpn-1.21.0-2.fc39.x86_64 in updates testing resolves connection problem there is still problem in Network Manager part. Network Manager adds argument --no-routes to openfortivpn command line. This argument should not be added.
(In reply to Michal Piotrowski from comment #6) > After upgrading to Fedora 39 ppp changed and while > openfortivpn-1.21.0-2.fc39.x86_64 in updates testing resolves connection > problem there is still problem in Network Manager part. Network Manager adds > argument --no-routes to openfortivpn command line. This argument should not > be added. Hello I made the upgrade Now Work perfectly Thanks team :)
So, I've updated NetworkManager-fortisslvpn in Fedora 39+ with the latest upstream snapshot which contains already the ppp 2.5 patches and some other stuff. There's also a patch that drops --no-routes as described in https://bugzilla.redhat.com/show_bug.cgi?id=2246228#c6. I can succesfully connect and use the VPN if SELinux is not in enforcing mode. With SELinux enforcing I get this error: INFO: Interface ppp0 is UP. INFO: Setting new routes... WARN: Could not set route to vpn server (Operation not permitted). WARN: Could not delete the current default route (Operation not permitted). WARN: Could not set the new default route (Operation not permitted). INFO: Tunnel is up and running. Without, everything works fine and I can use the VPN: INFO: Interface ppp0 is UP. INFO: Setting new routes... INFO: Tunnel is up and running. A quick audit2allow -a shows this one: #============= openfortivpn_t ============== #!!!! This avc can be allowed using the boolean 'domain_kernel_load_modules' allow openfortivpn_t kernel_t:system module_request; This is not correct and should not be required. By removing --no-routes we are now relying on openfortivpn to manage the routes while before it was NetworkManager's duty.
*** Bug 2250296 has been marked as a duplicate of this bug. ***
Just to be clear, assuming you have a valid openfortivpn configuration at /etc/openfortivpn/config, you can reproduce the NetworkManager-fortisslvpn problem by calling openfortivpn this way: # openfortivpn --no-routes --no-dns --pppd-use-peerdns=1 --pppd-accept-remote=1 \ <vpn_endpoint> --pppd-plugin /usr/lib64/pppd/2.5.0/nm-fortisslvpn-pppd-plugin.so You can see everything being set up by NetworkManager except for the default route.
Actually, the problem with the routes are with two extra ones. After connecting, I need to delete these two: <vpn_endpoint> dev ppp0 proto kernel scope link src <ip_of_ppp0> <vpn_endpoint> dev ppp0 proto kernel scope link src <ip_of_ppp0> metric 50 After deleting these two, it works.
I think I found the issue. From this comment onwards: https://github.com/adrienverge/openfortivpn/issues/1141#issuecomment-1822709455