The PPTP Client is a complex collection of components, and is difficult to diagnose without knowledge of how the components are used.

We present three diagrams showing processes and devices in a system that has a connection through an analog modem or ADSL service, and a PPTP tunnel within that connection. Large rectangles are processes (yellow). Small rectangles are devices (red), interfaces (blue) and sockets (green). Lines are data flows, and are bidirectional.

Normal Operation, Analog Modem

Our first diagram shows the normal operation of the PPTP Client on a system connected to the internet through an analog modem. Note that in this configuration there are two pppd processes, one for the internet connection, and one for the tunnel.

Figure 1 shows the following, reading from the top down;

• ttyS0, the device name for the serial port connected to the modem, which is dialled up to an internet service provider.

• pppd, the process responsible for managing the PPP connection through the modem.

• ppp0, the network interface through which packets will be exchanged with the internet.

  Up until this point, we have described a normal PPP dial-up connection.

• socket, a raw socket through which the GRE-to-PPP process exchanges GRE packets with the PPTP Server. GRE packets are an instance of IP packet, with the protocol field set to GRE. The routing table causes the kernel to send them out through ppp0.

• GRE-to-PPP, a process that translates the GRE over IP protocol used to reach the PPTP Server to the HDLC protocol used to speak to the pppd process that manages the tunnel data flow.

• pty, a psuedo-tty device that serves to connect the GRE-to-PPP process with the pppd process. It emulates the behaviour of a tty device, such as a serial port, but has no hardware associated with it.

• pppd, the process responsible for managing the PPP connection through the tunnel.

• ppp1, the network interface through which packets will be exchanged with the tunnelled network, which are the hosts on the secure side of the PPTP Server. The routing table causes the kernel to send these packets through this interface.

  Moving to the right hand lower portion of the diagram.

• socket, a UNIX domain socket through which the GRE-to-PPP and callmgr processes communicate.

• callmgr, the process responsible for maintaining the 'call' connection to the PPTP Server.

• socket, a TCP socket bound to port 1723 on the remote end, through which the 'call' connection data is exchanged with the PPTP Server. The routing table causes the kernel to send this data stream out through ppp0.

Figure 2 shows the conventional use of the PPTP Client on an ADSL service. The analog modem has been replaced with an ADSL router, connected to the eth0 interface. Note that as a result, there is only one pppd process, and ppp0 is the name of the network interface to the secure side of the PPTP Server.

Broken Routing Table

If the routing table is improperly set up, then the tunnel can form a loop. Known causes of this are:

• public IP address of the PPTP server matches the remote IP address of the tunnel, (solution, see our Routing HOWTO)
• use of the defaultroute option in the PPTP configuration, or;
• the use of ipchains or iptables rules that filter traffic,

• the red dotted line on the left represents GRE packets written to the raw socket by the GRE-to-PPP process that would normally be sent to the ppp0 interface. Instead, the routing table directs these packets out the ppp1 interface, causing the loop.

• the blue dotted line from ppp0 to the raw socket used by the GRE-to-PPP process represents packets arriving over the tunnel from the PPTP Server. The pppd process responsible for the tunnel will receive echo requests from the PPTP Server, and will respond. However, the response will be lost in the loop. It will generate echo requests itself, but they will be lost.

• the red dotted line on the right shows that the callmgr connection to the PPTP Server will also be disrupted. Packets directed at the server will enter the loop.

• the blue dotted line on the right from ppp0 to the callmgr socket shows that the callmgr connection will continue to receive, but any response will be lost in the loop.

Caveats

• none of the MPPE functionality is shown by these diagrams; it is handled by the pppd process for the tunnel using kernel modules at the data flow between the process and the tunnel interface.

• the connection between the GRE-to-PPP process and the callmgr process may not be correctly shown here. We await technical review by the development team.

• these diagrams only show the normal state once the tunnel is working, they don't show the state during connection.