-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NetworkManager problem with 1.20.4 on Linux #1120
Comments
It works for me on Ubuntu 22.04 with PPP 2.4.9. Please try from the command line, not Network Manager. |
I already stated that in my first entry - CLI works - NM GUI does not - downgrading to openfortivpn-1.20.3 makes NM GUI work again In short - this is the important details from the first entry:
|
i have the exact same issue, downgrading to 1.20.3 fixes it |
Have you opened a ticket against NetworkManager-fortisslvpn? |
just opened https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/63 and pointed to this issue |
I will revert 3b54df0, making its code optional. But chances are this will break PPP 2.5.0 again. |
With 3b54df0, macOS users massively report this issue: WARN: Could not get current default route (Parsing /proc/net/route failed). WARN: Protecting tunnel route has failed. But this can be working except for some cases. See adrienverge#1118. With 3b54df0, NetworkManager users on Linux report routing problems. See adrienverge#1120. Without 3b54df0, users on Linux with PPP 2.5.0 report this issue: Peer refused to agree to his IP address. See adrienverge#1114. Therefore, make the code optional, to cover all cases. Of course, this is a short term solution. We need to understand what happens and provide a real fix that doesn't involve options.
With 3b54df0, macOS users massively report this issue: WARN: Could not get current default route (Parsing /proc/net/route failed). WARN: Protecting tunnel route has failed. But this can be working except for some cases. See #1118. With 3b54df0, NetworkManager users on Linux report routing problems. See #1120. Without 3b54df0, users on Linux with PPP 2.5.0 report this issue: Peer refused to agree to his IP address. See #1114. Therefore, make the code optional, to cover all cases. Of course, this is a short term solution. We need to understand what happens and provide a real fix that doesn't involve options.
I'm experiencing the same issue, on my system it is assigning the VPN server address as the Peer address on the ppp0 interface. As a result the VPN can no longer reach the VPN server as all VPN traffic is routed via itself, the connection then gives up after 2.5 minutes when it times out. Manually setting the correct peer address and replacing the routes restores my VPN connectivity, and it no longer stops after 2.5 minutes. I'm seeing this on Arch with:
|
@pentaxslr We have released 1.20.5, which partially reverts 3b54df0 from 1.20.4, making its code optional. This will give us time to get to the bottom of this issue. Doesn't it work for you? |
I also seem to have this issue (CLI works but NM Gui not). I am on Arch and will test/report back as soon as the package has been updated to 1.20.5 |
Upgraded manually to 1.20.5, now everything works fine (ArchLinux + NetworkManager + NetworkManager-fortisslvpn + openfortivpn), on 1.20.4 experienced the same issue as described by the OP |
This comment was marked as off-topic.
This comment was marked as off-topic.
@Utini2000 @mexus Please note that 1.20.5 is a temporary revert of the change in 1.20.4. I believe the change will eventually have to be re-applied, so this issue needs to be fixed in NetworkManager-fortisslvpn. Do not hesitate to comment in NetworkManager-fortisslvpn#63 instead of here, if you want the issue fixed. |
Thanks @DimitriPapadopoulos ! By the way, do you have any thoughts on what could have gone wrong with the plugin? |
For now, I haven't found the time to look into it, but:
We probably just need to make an exception for the VPN server address itself when routing through the tunnel (there should probably be an exception for the DHCP server too but that's another issue). Patches welcome, here (at least for macOS) and in NetworkManager-fortisslvpn! |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
The following versions under Fedora 39 Silverblue exhibit the same issue: openfortivpn-1.21.0-2.fc39.x86_64 What exactly is the status on this issue? |
@ziswiler Which issue? Have you tried openfortivpn from the command line? If not, please do and report back. |
Yes, but the NetworkManager integration still fails just as described in this ticket. |
It's best to create or a ticket, or follow an existing one, in the NetworkManager-fortisslvpn page. In the meantime, #1171 and this ticket #1120 probably describe the problem best. |
Edit: turns out this is the default since #1153 |
Any progress on it? |
Hello,
I see what appears to be similar problems as reported in #1118
I'm running ArchLinux
Using a (know working) connection profile from NetworkManager GUI
I'm able to authenticate and establish VPN connection with openfortivpn-1.20.4 - but no data gets through the VPN
But I'm able to connect with openfortivpn-1.20.4 started manually from the CLI - and data will flow through the VPN
Downgrading to openfortivpn-1.20.3 solves the problem - connection profiles via NetworkManager GUI is working again
With openfortivpn-1.20.4 - connections established through NetworkManager GUI connection profiles terminales after 2.5 minuttes with this message - as you can see it is a one-way connection (Sent 18110 bytes, received 0 bytes.)
pppd[6025]: No response to 4 echo-requests
NetworkManager[6025]: No response to 4 echo-requests
NetworkManager[6025]: Serial link appears to be disconnected.
NetworkManager[6025]: Connect time 2.5 minutes.
NetworkManager[6025]: Sent 18110 bytes, received 0 bytes.
pppd[6025]: Serial link appears to be disconnected.
pppd[6025]: Connect time 2.5 minutes.
pppd[6025]: Sent 18110 bytes, received 0 bytes.
BTW: archlinux is using pppd version 2.4.9 (package name ppp-2.4.9-3)
Looking at your commit log between versions 1.20.3 and 1.20.4 - I see only one commit - adding option "ipcp-accept-remote"
Could it be that you have created some sort of incompatibility with pppd versions < 2.5.0 ?
The text was updated successfully, but these errors were encountered: