Arch Linux User Repository

It always adds the default route "default dev ppp0 scope link", even though it was added in the configuration [ipv4] ignore-auto-routes=true never-default=true route1=10.0.0.0/8 The previous version didn't do this

I also confirm that adding NAN-aurf's suggested flags fixes the issue. Thanks @NAN-aur

During building I'm getting an error: configure.ac:15: error: possibly undefined macro: dnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. I have automake 1.16.5-2.

I have tryed NaN-aur's "pacth" and now the connection is working for me.

@NAN-aur, you're correct. Thanks for the fix.

I got the plugin working on my system by patching it. First --pppd-accept-remote should be added to arguments of openfortivpn. Then a connection can be established, although routing doesn't work. Thus I removed the --no-routes argument of openfortivpn and it worked. I can't tell why it doesn't work with the --no-routes argument because the routes don't look wrong, though the routes aren't identical. I didn't spent too much time debugging this, but once the connection started working after some time and after changing the routes. I didn't spent much time on it because I wasn't able to reproduce it the second time I tried it. Maybe there is a race condition or a too early state transition in the plugin.

As workaround I added the following to the PKGBUILD: sed -i 's/"--no-routes"/"--pppd-accept-remote"/g' src/nm-fortisslvpn-service.c

@guigqui: Your observation is not related to the specific issue. Running pppd as root doesn't fix the issue. The only issue when running pppd as nobody is that the DNS server will never be updated (assuming a default installation without additional scripts).

Like @Terseus commented, if you change de option in /etc/ppp/options the VPN works vía openfortivpn. Via networkmanager it looks like it works but it doesnt, i think that is beacause networkmanager plugin runs pppd as nobody user instead root.

P.D.: Sorry for my english

Waiting for the Peer refused to agree to his IP address bug to be resolve, you can directly connect from the terminal by launching sudo openfortivpn --pppd-accept-remote your.vpn.host -u your_username

Thanks @Terseus for the CLI flag ^^

What @Terseus comments, it happens to me too.

After upgrading both ppp and the client, I can no longer connect to the VPN that worked previously.

The following error is shown in journalctl:

NetworkManager[71723]: INFO:   Negotiation complete.
NetworkManager[71724]: Peer refused to agree to his IP address
NetworkManager[71724]: Connect time 0.1 minutes.
NetworkManager[71724]: Sent 1137 bytes, received 1105 bytes.
pppd[71724]: Peer refused to agree to his IP address
pppd[71724]: Connect time 0.1 minutes.
pppd[71724]: Sent 1137 bytes, received 1105 bytes.

Looks like I'm not the only one: https://bbs.archlinux.org/viewtopic.php?id=288717

The client openfortivpn have this flag:

--pppd-accept-remote          Invoke pppd with option 'ipcp-accept-remote'.
                              It might help avoid errors with PPP 2.5.0.

However I don't know how to pass this flag to the client invoked by the plugin, I've tried to add the following to the config file without success:

pppd-accept-remote=true

This raises an error by NetworkManager about how the property is not supported in the config file.

Now, if I add the option ipcp-accept-remote to /etc/ppp/options the VPN connects but I lose my outgoing Internet connection and the VPN resources are not accessible, making pointless that it connects or not.

Any ideas?

thx solved