|
|
|
|
|
 |
project |
|
|
|
|
|
|
|
documentation |
|
|
|
|
|
|
team |
|
|
|
|
|
|
|
 |
|
 |
| |
PPTP Client
Diagrams
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 - Normal Operation, Analog Modem
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.
Normal Operation, ADSL Service
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.
Figure 2 - Normal Operation, ADSL Service
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,
Figure 3
shows the effect.
Figure 3 - Broken by an IP Loop
- 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.
Eventually, the callmgr will be notified by the PPTP Server that the
connection is closed.
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.
(How the diagrams were produced.)
|