Comment 10 for bug 1511330

After some tinkering I've found a somewhat different workaround (of you might call it a fix) and a probable immediate cause of this behavior.

My VPN server has an address of 192.168.17.1 and it assings a range 192.168.17.33 - 192.168.17.62 to clients. I used to manually add the following routes (this is supposed to like the relevant dialog):
 Address Netmask Gateway Metric
 192.168.17.0 255.255.255.0 192.168.17.1 1
 172.16.32.0 255.255.252.0 192.168.17.1 1

This did work because (I believe, cannot really bother with testing now) Network Manager or PPTP plugin added a route to the VPN gateway (192.168.17.1 in my case). And it no longer does. Without this route further routes are considered invalid. This here might be a bug or it might have been redesigned — I don't know.

Luckily there is way to enter link scoped routes in that dialog, although unintuitive: you just leave the "Gateway" field empty. Like this:
 Address Netmask Gateway Metric
 192.168.17.0 255.255.255.0 1
 172.16.32.0 255.255.252.0 1
The "OK" button turns inactive after you delete a gateway, so you have to tab or click some other field for it to come back.

After this the connection works and the following routes get added to the routing table:
 > ip route
 default ...
 <vpn gateway external ip> via <your usual first hop router>
 ...
 172.16.32.0/22 dev ppp0 proto static scope link metric 1
 192.168.17.0/24 dev ppp0 proto static scope link metric 1
 192.168.17.35 dev ppp0 proto kernel scope link src 192.168.17.35 metric 50
 ...

Hope this helps someone else