Stop using ipv4.gateway for IPCP peer address - breaks never-default and forces unwanted default routes

[noobpwnftw]

Current design is flat-out broken. bdd7501 wires IPCP peer negotiation to ipv4.gateway, but in NetworkManager “gateway” means default route next hop. As a result, if I want to advertise a peer IP via IPCP I’m forced to set a “gateway”, which immediately collides with ipv4.never-default. Those two options are now mutually exclusive: either I accept NM shoving in a bogus default route, or I give up on IPCP negotiation for my desired IP. There’s no sane middle ground. Please stop overloading gateway for two unrelated things - use a dedicated VPN key for the IPCP remote instead of hijacking routing semantics.

[dkosovic]

Happy to take a pull request that fixes the issue.

My workplace no longer uses L2TP/IPsec, so I'm only doing limited maintenance.

That commit# bdd7501 was based on :

• https://gitlab.gnome.org/GNOME/network-manager-sstp/-/commit/fcfdf38da764b2d69533192bc4a960afe7ed33ce

Not sure if we should get the network-manager-sstp maintainer involved who is also one of the ppp-2.5 maintainers.

[noobpwnftw]

I ended up just rolling a GRE tunnel by hand.

What here is a lack of distinction, one should never set such a dial connection's ip mode to manual, as it is always negotiated, even with IPCP, otherwise the negotiated IP will be added to the interface along side the manual one, sometimes with a different scope, sometimes completely different. So I suggest adding such fields in vpn.data instead and reject manual IP settings if possible.

These projects are probably long inactive due to the lack of interest, and it is indeed ridiculously counter-intrutitive these days to get this working at all, along with SELinux and systemd-driven NetworkManager isolation fuss.

I'm surprised that there is actually someone to hear the whine within hours, kudos to you. But I think we can agree fixing it benefits probably no one.