This is really an upstream bug, but as I have a workaround including
new support code for split-tunnel VPNs which is currently not available
under linux, I am filing it here and suggest that the "splitp" script
included here be included in /usr/doc/ppp/examples/scripts/ so that
Debian users have it handy until support for these features appears.

This bug occurs when using Linux as a client to a VPN.  Specifically
I have seen it occur under racoon/ipsec-tools, but it probably affects
any ppp session that is tunnelled through an IP-based tunnel.

When connecting to a remote access server, the address handed to a
client (in our case a Debian box) is sometimes meaningless for layer 3
routing purposes, and can be arbitrary.  VPNs sometimes will hand out
the same address via LCP as they use for the encapsulating IP tunnel
endpoint.

When LCP completes, PPP will install a host route sending all
traffic to the LCP-obtained RAS address into the ppp interface.  There
seems to be no option available to prevent this from happening.  This
means all PPP packets enter the PPP tunnel, are encapsulated, and if
the tunnel endpoint address is routed into the ppp interface as
described above, instead of sending the encapsulated packet by IP, it is
sent back into the PPP tunnel and encapsulated a second time, and so
on.  This quickly maxes CPU for the ppp process or the process driving
it (e.g. xl2tpd) though Linux seems to be pretty good at not allowing this
condition to bring the system to its knees.

It can be argued that such VPNs are misconfigured, but even as such
they are not unusable and this sort of stuff happens in real life.

Attached is a script intended to remove this host route immediately
after a ppp session is established, which can be installed in
/etc/ppp/ip-up.d/.  In addition, this script performs all the functions
needed to acquire split tunnel static network routes from a VPN/RAS
which implements this option (Windows XP clients use this mechanism.)
Failing that, the script will use classful routing to determine a
network route to install, which is how OSX and Windows Vista/2000/ME
behave when connecting to a split tunnel, and how XP behaves when there
is no static route information offered.

At minimum, upstream needs to add an option to completely prevent
pppd from meddling with routes.  Better would be a ppp plugin which
does what the attached script does, before any routes are installed.