1. PPTP is a Microsoft's Proprietary Protocol. I think it was superceded by L2TP, but will need to confirm this. Yet, i find PPTP to be pretty good, if problems with weak encrytpions is not to be taken into consideration.
2. PPTP basically encapsulates PPP packets in a GRE header and tunnels it to the other end.
3. To support PPTP protocol on linux, the kernel (on both client and server) has to support MPPE (Microsoft Point-to-point encryption, RFC3078). RedHat 8.0/9.0 kernels do not support MPPE by default, and hence one has to install certain kernel modules. This can be done in one of the following two ways:
   • Download and install an rpm from this site, which also has useful instructions.
     
     NOTE: Use "uname -r" to determine your kernel version, and download the appropriate rpm as needed. This is extrememly important as the modules created by this rpm are kernel-version specific. Hence if you upgrade the kernel, you will have to reinstall these kernel-mppe modules.
     
     On Mia I have installed for two different kernels (2.4.20-9 and 2.4.20-13.9), as apparent from the output below:

     [shashank@mia ppp]# rpm -qi kernel-mppe
     Name        : kernel-mppe                  Relocations: (not relocateable)
     Version     : 2.4.20                            Vendor: (none)
     Release     : 9                             Build Date: Tue Apr 29 04:02:33 2003
     Install Date: Tue May 27 12:24:12 2003      Build Host: lenny.lan
     Group       : Networking/Daemons            Source RPM: kernel-mppe-2.4.20-9.src.rpm
     Size        : 47086                            License: BSD without advertisement clause
     Signature   : (none)
     Packager    : R. de Vroede 
     URL         : http://www.poptop.org
     Summary     : ppp-MPPE kernel modules for PPTP.
     Description :
     MPPE is an encryption technology developed by Microsoft to encrypt...
     ---SNIP---
     Name        : kernel-mppe                  Relocations: (not relocateable)
     Version     : 2.4.20                            Vendor: (none)
     Release     : 13.9                          Build Date: Mon May 19 07:17:24 2003
     Install Date: Fri May 30 11:26:06 2003      Build Host: lenny.lan
     Group       : Networking/Daemons            Source RPM: kernel-mppe-2.4.20-13.9.src.rpm
     Size        : 47086                            License: BSD without advertisement clause
     Signature   : (none)
     Packager    : R. de Vroede 
     URL         : http://www.poptop.org
     Summary     : ppp-MPPE kernel modules for PPTP.
     Description :
     MPPE is an encryption technology developed by Microsoft to encrypt...
     ---SNIP---
     

   • If you are using a stock linux kernel (say, 2.4.20), then you might not find an apprpriate RPM for your kernel. In this case, use the kernelmod to install the appropriate modules.

papers@mia:~/public_html/volans> rpm -qi ppp
Name        : ppp                          Relocations: (not relocateable)
Version     : 2.4.2_cvs_20030514                Vendor: (none)
Release     : 1                             Build Date: Tue May 13 19:16:51 2003
Install Date: Wed May 28 11:26:33 2003      Build Host: spice.lan
Group       : System Environment/Daemons    Source RPM: ppp-2.4.2_cvs_20030514-1.src.rpm
Size        : 353966                           License: distributable
Signature   : (none)
Summary     : The PPP (Point-to-Point Protocol) daemon.
Description :
The ppp package contains the PPP (Point-to-Point Protocol) daemon....

1. http://pptpclient.sourceforge.net or
2. http://quozl.netrek.org/pptp/ppp.phtml.

• Kernel with MPPE support ( Check to make sure)
• PPP with MPPE enabled ( Check to make sure)

1. The PPTP server (PoPToP) reads a configuration file /etc/pptpd.conf by default, unless you specify something else at the command line. Do man pptpd to check the other command line options. However, we will put all the required options in /etc/pptpd.conf. Below I list the contents of the /etc/pptpd.conf:

   shashank@zidler:/etc# cat pptpd.conf
   speed 115200                    #Speed of the Interface.
   option /etc/ppp/options.pptpd   #Options files to be used by pppd
   debug                           #put all the debugging mesages in /var/log/messages.
   localip 192.168.254.201         #This is the localip. Also a range can be specified.
   remoteip 192.168.254.200        #This is the remoteip. Also a range can be specified.
   listen 131.193.50.184           #This is the interface you should listen to honor requests.
   

2. Note the line option /etc/ppp/options.pptpd in the above file. It is used to pass command line options to pppd. Below I list the contents of /etc/ppp/options.pptpd. Click here to find out why did i use these specific options?

   shashank@zidler:~> cat /etc/ppp/options.pptpd
   name zidler
   
   lock
   dump
   logfd 2
   #debug
   #logfile /var/log/pptpd.log
   
   auth
   require-mschap-v2
   require-mppe-128
   
   #noccp
   novj
   novjccomp
   nopcomp
   noaccomp
   nobsdcomp
   nodeflate
   
   ipparam 192.168.0.0
   
   #Provide DNS server addresses to MS clients.
   #ms-dns 131.193.32.254
   
   

   Perhaps the most important options in the above file are name, auth (or noauth), require-mppe, require-mschap-v2. The "name" option tells the server what its name is. By default this value is "PPTP", which I did not want to use. So I named my server as "zidler". This has great repurcussions on the contents of /etc/ppp/chap-secrets, /etc/ppp/pap-secrets and other secret files. For e.g. below I list the contents of /etc/ppp/chap-secrets file.

   shashank@zidler:/etc/ppp# cat chap-secrets
   # Secrets for authentication using CHAP
   # client        server  secret                  IP addresses
   mia             zidler  mia123        *
   

3. Start the Poptop server using the command: pptpd -f. The -f option is only used to keep the poptop server in the foreground. More information on different options can be obtained by doing pptpd --help

1. Client configuration can be done using the pptp-command command, which is a simple perl script to start the Tunnel. An Interactive session will start. Follow the instructions to create.
   • A Chap-secret, with local name set to mia, Remote Name set to zidler (name of PoPToP server), a secret password mia123 (in our case).
   • A tunnel, with tunnel name as test2 (say), Server IP of zidler.ece.uic.edu, local name of mia and remotename of zidler. No need to add any routes right now.
2. pptp-command should create a file by the name test2 in /etc/ppp/peers/. A peek into this file, will result something like below:

   [shashank@mia ~]# cat /etc/ppp/peers/test2
   name mia
   remotename zidler
   ipparam test2
   file /etc/ppp/options.pptp
   

3. Note the last line in the above file, which denotes the options files with which pppd will be invoked. I have placed the following options in /etc/ppp/options.pptp. Click here to find out why did i use these specific options?

   ---------------------------
   
   [shashank@mia ~]# cat /etc/ppp/options.pptp
   name mia
   
   lock
   dump 
   logfd 2 
   debug 
   #logfile /var/log/pptpd.log
   
   noauth 
   #require-mschap-v2
   require-mppe-128
   #nomppe
   
   #noccp 
   novj 
   novjccomp 
   nopcomp 
   noaccomp
   nobsdcomp
   nodeflate
   
   ipparam 192.168.2.0
   
   

4. After all this you can start using the tunnel, by using the start option in the interactive pptp-command session. You should get the following log. Note the packet exchanges. The output below has been slightly modified.

   --SNIP--
   1. sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x4c976cdf>]
   2. rcvd [LCP ConfReq id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x7b5dca0e>]
   3. sent [LCP ConfAck id=0x1 <asyncmap 0x0> <auth chap MS-v2> <magic 0x7b5dca0e>]
   4. rcvd [LCP ConfAck id=0x1 <asyncmap 0x0> <magic 0x4c976cdf>]
   5. rcvd [CHAP Challenge id=0x1 <7a3d05555bdac699d0dce5530da01387>, name = "zidler"]
   6. sent [CHAP Response id=0x1 <af51bcc0894a92b4a6c98f895da26c410000000000000000...>, name = "mia"]
   7. rcvd [CHAP Success id=0x1 "S=C0BB40C5E0BEFC0D69D9190F0140F18A8E1DBFBD M=Welcome to zidler.ece.uic.edu."]
   8. Remote message: Welcome to zidler.ece.uic.edu.
   9. CHAP authentication succeeded
   10. sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
   11. rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
   12. sent [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
   13. rcvd [CCP ConfAck id=0x1 <mppe +H -M +S -L -D -C>]
   14. MPPE 128-bit stateless compression enabled
   15. sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]
   16. rcvd [IPCP ConfReq id=0x1 <addr 192.168.254.230>]
   17. sent [IPCP ConfAck id=0x1 <addr 192.168.254.230>]
   18. rcvd [IPCP ConfNak id=0x1 <addr 192.168.254.231>]
   19. sent [IPCP ConfReq id=0x2 <addr 192.168.254.231>]
   20. rcvd [IPCP ConfAck id=0x2 <addr 192.168.254.231>]
   21. local  IP address 192.168.254.231
   22. remote IP address 192.168.254.230
   23. Tunnel zidler is active on ppp0.  Local IP Address: 192.168.254.231
   

   You may get a different output, but I will try to give some insight into the different phases that ppp goes through. Lines 1-4 are the Link configuration phase. During this phase the two sides exchange parameters that need to be applied to the link. If any side cannot accept a parameter, it will outrightly reject it and the other side has to re-negotiate.
   
   This is followed by Authentication Phase (Lines 5-9). Since we were using MS-Chap-v2 authentication, it is the server(zidler) which starts the Chap authentication by sending a challenge (Line 5) followed by the client response (Line 6) and finally the server acknowledgement of success (Line 7).
   
   Lines 10-14 are the message exchanges for CCP (Compression Control Protocol), negotiating MPPE parameters. For more information on this exchange, click here.
   
   Then comes the IP configuration stage (Lines 15-22), where both the sides negotiate IP addresses and other related options.
   
   
5. After the interface comes up, /etc/ppp/ip-up script is executed. This script is shown below. Note, how I have added the route in /etc/ppp/ip-up.local script, called from /etc/ppp/ip-up and also shown below

   [shashank@mia ppp]# cat ip-up
   #!/bin/bash
   # This file should not be modified -- make local changes to
   # /etc/ppp/ip-up.local instead
   PATH=/sbin:/usr/sbin:/bin:/usr/bin
   export PATH
   LOGDEVICE=$6
   REALDEVICE=$1
   [ -f /etc/sysconfig/network-scripts/ifcfg-${LOGDEVICE} ] && /etc/sysconfig/network-scripts/ifup-post ifcfg-${LOGDEVICE}
   [ -x /etc/ppp/ip-up.local ] && /etc/ppp/ip-up.local "$@"
   exit 0
   
   ----------------------------------------------------------------------------------------
   
   [shashank@mia ppp]# cat ip-up.local
   #!/bin/sh
   # Sample of the ip-up script.
   # This is called when the CIPE interface is opened.
   # Arguments:
   #  $1 interface     the ppp interface
   #  $2 terminal      the terminal
   #  $3 speed         Speed used on the interface
   #  $4 local         IP address of our CIPE device
   #  $5 remote        IP address of the remote CIPE device
   #  $6 arg           argument supplied via "ipparam" option for pppd.
   
   umask 022
   PATH=/sbin:/bin:/usr/sbin:/usr/bin
   # SK Add route to peer's network
   route add -net $6 gw $5 netmask 255.255.255.0
   now=`date "+%b %d %T"`
   echo "$now UP   $*" >> /var/log/pptpd.log
   exit 0
   
   

6. Similarly there is /etc/ppp/ip-down, which gets called whenever the tunnel is stopped (or the interface is brought down). This script also calls /etc/ppp/ip-down.local. Both of them are shown below.

   [shashank@mia ppp]# cat ip-down
   #!/bin/bash
   # This file should not be modified -- make local changes to
   # /etc/ppp/ip-down.local instead
   PATH=/sbin:/usr/sbin:/bin:/usr/bin
   export PATH
   
   LOGDEVICE=$6
   REALDEVICE=$1
   [ -x /etc/ppp/ip-down.local ] && /etc/ppp/ip-down.local "$@"
   /etc/sysconfig/network-scripts/ifdown-post ifcfg-${LOGDEVICE}
   exit 0
   ---------------------------------------------------------------
   [shashank@mia ppp]# cat ip-down.local
   #!/bin/sh
   # Sample of the ip-up script.
   # This is called when the CIPE interface is opened.
   # Arguments:
   #  $1 interface     the ppp interface
   #  $2 terminal      the terminal
   #  $3 speed         Speed used on the interface
   #  $4 local         IP address of our CIPE device
   #  $5 remote        IP address of the remote CIPE device
   #  $6 arg           argument supplied via "ipparam" option for pppd.
   
   umask 022
   PATH=/sbin:/bin:/usr/sbin:/usr/bin
   
   # SK Add route to peer's network
   route del -net $6 gw $5 netmask 255.255.255.0
   
   now=`date "+%b %d %T"`
   echo "$now DOWN   $*" >> /var/log/pptpd.log
   /bin/cat /dev/null > /var/log/pptpd.log
   exit 0
   

1. The below diagram traces the path taken by a packet as it travels over the tunnel formed by PPTP.
   
   
2. The UDP/IP/Ethernet layers add known amount of header/trailer which are trivial to find out. Hence, I will not explain them here. I will concentrate only on the overhead added by PPP (with and without MPPE) and PPTP layer.
3. Let us first discuss the overhead added by PPP under the following two situations:
   • PPP with no MPPE: In this case, PPP protocol adds a maximum overhead of 8 bytes and a minimum of 5 bytes [The Point-to-Point Protocol (PPP), RFC1661, §2 ] [PPP in HDLC-like Framing, RFC1662, § 3.1] The PPP frame format from the RFC's is reproduced below for future reference:
     (Note: Padding field is optional and our PPP implementation does not use padding)

     +----------+----------+----------+----------+-------------+---------+----------+----------+
     |   Flag   | Address  | Control  | Protocol | Information | Padding |   FCS    |   Flag   |
     | 01111110 | 11111111 | 00000011 | 8/16 bits|      *      |    *    |16/32 bits| 01111110 |
     +----------+----------+----------+----------+-------------+---------+----------+----------+
     

   • PPP with MPPE: In this case, apart from the normal headers ,as discussed in the point above, PPP also tags the information filed with an additional MPPE header(2) and a protocol field header(2) [MPPE, RFC3078, § 3.1]. This is shown in figure below:

     .......+----------+----------+-------------+-------------+-------------+---------+----------+.....
     .......| Control  | Protocol |   MPPE HDR  |   Protocol  | Information | Padding |   FCS    |.....
     .......| 00000011 | 8/16 bits|   16 bits   |   16 bits   |      *      |    *    |16/32 bits|.....
     .......+----------+----------+-------------+-------------+-------------+---------+----------+.....
                                                <--ENCRYPTED--> <----ENCRYPTED-------->
     
     

   PPP uses character/byte stuffing to escape the flags characters.
4. The PPTP protocol, strips of the flags, FCS and any stuffed bytes from the PPP frames [PPTP, RFC2637, § 4], and adds a modified GRE header [PPTP, RFC2637, § 4.1]. We have reproduced this modified GRE header for future reference.

     0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |C|R|K|S|s|Recur|A| Flags | Ver |         Protocol Type         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Key (HW) Payload Length    |       Key (LW) Call ID        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Sequence Number (Optional)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               Acknowledgment Number (Optional)                |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
   

   For data packets the 4 byte Acknowledgement field is not present, thus giving a GRE header of 12 bytes.
5. Thus theoretically we can calculate the total overhead resulting from PPTP for the following two scenario's for a 100 byte packet sent by an Application using UDP.
   • PPP with no MPPE: A 100 byte data packet sent to the peer, using UDP will have the following headers appended to it.

     Application Data     100 
     UDP                    8            
     IP                    20
     PPP (no MPPE)          8
     PPTP                  -4 (Removes FCS, Flags from PPP frame)
     PPTP                  12 (GRE header)
     IP                    20
     ethernet              14
     ------------------------
     Total:               178
     ------------------------
     

     Thus total theoretical overhead is 78 bytes.
     Disabling compression in PPP, we conducted a series of experiments with varying application input sizes. The input data for this experiment was totally random An example of such data is shown below:

     seq_no: 0
     Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3;                             
     "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/
     U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4q                   
     

     This data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
     The results are presented ( NO Compression + NO MPPE).
   • PPP with MPPE: If MPPE is used, then the PPP layer adds an extra 4 bytes (MPPE header(2) + Protocol (2)). MPPE uses RC4, which is a stream cipher. Hence the encrypted data output'd by RC4 has the same length as the input. Thus proceeding as above we can calculate the theoretical overhead to be 82 bytes.
     Disabling compression in PPP, we conducted a series of experiments with varying application input sizes as above. The results are presented (NO Compression + MPPE).

1. The PPTP daemon does not provide any compression routines of its own. Hence we have to rely on the compression routines provided by PPP. These can be enabled by commenting out the appropriate options in the the PPP options file. Click here to find out which options you would need to comment out.
2. One interesting thing to note is that, when MPPE is enabled, it disables all other PPP compression routines, except PPP header compression, where the address and control fields are eliminated from a PPP frame, and protocol field is reduced to just one byte (instead of 2).
3. We conducted a series of experiments with varying application input sizes. The input data for this experiment was totally random An example of such data is shown below:

   seq_no: 0
   Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3;                             
   "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/
   U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4q                   
   

   This data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
   The results are presented for two cases:
   1. Full Compression but no encryption (Compression + No MPPE). Using full compression (with no encryption), it is not possible to estimate the amount of overhead, as the amount of compression really depends on the entropy in the data. It is entirely possible for the data on the wire to be lesser in size to the input data. For e.g. when we used an input data of size 1200 bytes (each having a value "S"), we found that the packet size on the wire was just 130 Bytes.
   2. Full Compression and full encryption (Compression + MPPE). In this case, since MPPE disables all other compression routines, except PPP header compression, we can estimate the overhead in a similar way that we calculated for the No Compression + MPPE case discussed here. Here the PPP layer replaces the 4 byte (address + control + Protocol field) with a one byte Protocol field. Thus all other things remaining same, we can say that the overhead is around (82 - 3 =) 79 bytes

1. PPTP tunnels, do not have inbuilt routing mechanisms. As a result the user has to take care of establishing routes to remote networks. This can be done in the following ways:
   • Static routes can be added after the PPP link comes up. I used this method, since the other methods failed for me.

     route add -net network/netmask dev $interface 
     

     Although the above method is simple for small networks, it becomes exceedingly difficult to maintain such routes once your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network.
   • Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.

1. The PPTP protocol make use of the authentication, encryption and compression services provided by PPP. Hence any proprietary algorithm plug-in's must be developed and integrated into PPP, rather than PPTP. Also only the following algorithms are available from PPP:

   authentication: pap, chap, ms-chap, ms-chap-v2
   encryption: rc4
   compression: zlib, bsdcomp
   

1. The PPTP solution for forming VPN's is highly unscalable. (This may not be true
2. I think will be used only in Road Warrior kind of scenarios.
3. For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.