Package: ppp Version: 2.4.4rel-9 Severity: normal 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. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'stable') Architecture: i386 (i686) Kernel: Linux 2.6.18charon (PREEMPT) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/bash Versions of packages ppp depends on: ii libc6 2.6.1-5 GNU C Library: Shared libraries ii libpam-modules 0.99.7.1-4 Pluggable Authentication Modules f ii libpam-runtime 0.99.7.1-4 Runtime support for the PAM librar ii libpam0g 0.99.7.1-4 Pluggable Authentication Modules l ii libpcap0.8 0.9.7-1 System interface for user-level pa ii netbase 4.30 Basic TCP/IP networking system ii procps 1:3.2.7-4.1 /proc file system utilities ppp recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
