Skip to content
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

Open
UffeJakobsen opened this issue Jun 22, 2023 · 22 comments
Open

NetworkManager problem with 1.20.4 on Linux #1120

UffeJakobsen opened this issue Jun 22, 2023 · 22 comments

Comments

@UffeJakobsen
Copy link

UffeJakobsen commented Jun 22, 2023

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 ?

@DimitriPapadopoulos
Copy link
Collaborator

It works for me on Ubuntu 22.04 with PPP 2.4.9.

Please try from the command line, not Network Manager.

@UffeJakobsen
Copy link
Author

UffeJakobsen commented Jun 22, 2023

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:

  1. From NM GUI: I'm able to authenticate and establish VPN connection with openfortivpn-1.20.4 - but no data gets through the VPN

  2. From CLI: I'm able to authenticate and establish VPN connection with openfortivpn-1.20.4 - and data will flow through the VPN

  3. Downgrading to openfortivpn-1.20.3 solves the problem from 1) - connection profiles via NetworkManager GUI is working again

@ironashram
Copy link

i have the exact same issue, downgrading to 1.20.3 fixes it

@DimitriPapadopoulos
Copy link
Collaborator

Have you opened a ticket against NetworkManager-fortisslvpn?

@ironashram
Copy link

just opened https://gitlab.gnome.org/GNOME/NetworkManager-fortisslvpn/-/issues/63 and pointed to this issue

@DimitriPapadopoulos
Copy link
Collaborator

I will revert 3b54df0, making its code optional. But chances are this will break PPP 2.5.0 again.

DimitriPapadopoulos added a commit to DimitriPapadopoulos/openfortivpn that referenced this issue Jun 22, 2023
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.
DimitriPapadopoulos added a commit that referenced this issue Jun 22, 2023
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.
@pentaxslr
Copy link

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:

networkmanager 1.42.6-1
networkmanager-fortisslvpn 1.4.0-2
openfortivpn 1.20.4-1

@DimitriPapadopoulos
Copy link
Collaborator

@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?

@Utini2000
Copy link

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

@mexus
Copy link

mexus commented Jun 26, 2023

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

@DimitriPapadopoulos

This comment was marked as off-topic.

@DimitriPapadopoulos
Copy link
Collaborator

@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.

@mexus
Copy link

mexus commented Jun 26, 2023

@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?

@DimitriPapadopoulos
Copy link
Collaborator

DimitriPapadopoulos commented Jun 27, 2023

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:

  1. The need for this change is explained in Pass ipcp-accept-remote to pppd #1111 (comment):

    The change from this PR disables enforcement of the remote IP when one is explicitly configured. It is unlikely that the VPN server would ever accept "169.254.2.1" as its address.

    The remote address is hardcoded here:

    ":169.254.2.1", // <local_IP_address>:<remote_IP_address>

  2. An effect of this change is explained in NetworkManager problem with 1.20.4 on Linux #1120 (comment):

    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.

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!

@pkubaj

This comment was marked as off-topic.

@DimitriPapadopoulos

This comment was marked as off-topic.

@ziswiler
Copy link

The following versions under Fedora 39 Silverblue exhibit the same issue:

openfortivpn-1.21.0-2.fc39.x86_64
NetworkManager-fortisslvpn-1.4.0-5.fc39.x86_64
NetworkManager-fortisslvpn-gnome-1.4.0-5.fc39.x86_64

What exactly is the status on this issue?

@DimitriPapadopoulos
Copy link
Collaborator

@ziswiler Which issue? Have you tried openfortivpn from the command line? If not, please do and report back.

@ziswiler
Copy link

Yes, but the NetworkManager integration still fails just as described in this ticket.

@DimitriPapadopoulos
Copy link
Collaborator

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.

@pdecat
Copy link

pdecat commented Oct 8, 2024

Note: the upcoming Ubuntu 24.10 release comes with ppp 2.5.0, and thus requires passing --pppd-accept-remote, otherwise the No response to 4 echo-requests/Serial link appears to be disconnected happens.

Edit: turns out this is the default since #1153

@Neustradamus
Copy link

Any progress on it?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

10 participants