pptp - PPTP driver

       This  manual  page  was  written  by James Cameron <james.cameron@hp.com> from text contributed by Thomas
       Quinot <thomas@debian.org>, for the Debian GNU/Linux system.  The description of the available statistics
       was written by Chris  Wilson  <chris@netservers.co.uk>.  Updates  for  the  Debian  distribution  by  Ola
       Lundqvist <opal@debian.org>.

                                                                                                         PPTP(8)

pptp  establishes  the  client side of a Virtual Private Network (VPN) using the Point-to-Point Tunneling
       Protocol (PPTP).  Use this program to connect to an employer's PPTP based VPN, or to  certain  cable  and
       ADSL service providers.

       By  default,  pptp  establishes  the PPTP call to the PPTP server, and then starts an instance of pppd to
       manage the data transfer.  However, pptp can also be run as a connection manager within pppd.

ConnectiontoaMicrosoftWindowsVPNServer

       pppd  noauth  nobsdcomp  nodeflate  require-mppe-128  name  domain\\\\username  remotename PPTP pty "pptp
       10.0.0.5 --nolaunchpppd"

       Note that the chap-secrets file used by pppd must include an entry for domain\\username

       pptp - PPTP driver

       The first non-option argument on the pptp command line must be the host name or IP address  of  the  PPTP
       server.

       All  long  options  (starting  with "--") are interpreted as pptp options, and a fatal error occurs if an
       unrecognised option is used.

       All command-line arguments which do not start with "-" are interpreted as ppp options, and passed  as  is
       to pppd unless --nolaunchpppd is given.

       --phone<number>
              Pass <number> to remote host as phone number

       --nolaunchpppd
              Do  not launch pppd but use stdin as the network connection.  Use this flag when including pptp as
              a pppd connection process using the pty option.  See EXAMPLES.

       --quirks<quirk>
              Work around a buggy PPTP implementation, adopts special case handling for particular PPTP  servers
              and ADSL modems.  Currently recognised values are BEZEQ_ISRAEL only

       --debug
              Run in foreground (for debugging with gdb)

       --sync Enable Synchronous HDLC (pppd must use it too)

       --timeout<secs>
              Time to wait for reordered packets (0.01 to 10 secs)

       --nobuffer
              Completely disables buffering and reordering of packets.  Any --timeout specified will be ignored.

       --idle-wait<secs>
              Time to wait before sending a control connection echo request.  The RFC2637 default is 60 seconds.

       --max-echo-wait<secs>
              Time  to  wait for an echo reply before closing the control connection.  The RFC2637 default is 60
              seconds.

       --logstring<name>
              Use <name> instead of 'anon' in syslog messages

       --localbind<addr>
              Bind to specified IP address instead of wildcard

       --rtmark<n>
              Use specified policy routing mark for all packets.  This causes both the TCP control  connection's
              packets  as well as the GRE packets to bear the given policy routing / netfilter mark. This can be
              used with iprule (from iproute2) to use a separate routing table for the pptp client.

              (requires root privileges or the CAP_NET_ADMIN capability.)

       --nohostroute
              Do not configure a host route pointing towards the PPTP server.  (cf. ROUTING below)

       --loglevel<level>
              Sets the debugging level (0=low, 1=default, 2=high)

       --test-type<n>
              Enable packet reordering tests that damage the integrity of the packet stream to the server.   Use
              this  only  when  testing  servers.   Zero  is the default, and means that packets are sent in the
              correct order.  A value of one (1) causes a  single  swap  between  two  packets,  such  that  the
              sequence  numbers  might  be  1  2  3  4  6  5 7 8 9.  A value of two (2) causes ten packets to be
              buffered, then sent out of order but ascending, such that the sequence numbers might be 1 2 3 4 16
              6 7 8 9 10 11 12 13 14 15 17 18 19 20.  A value of three (3) causes ten packets  to  be  buffered,
              then sent in the reverse order, like this; 1 2 3 4 16 15 14 13 12 11 10 9 8 7 6 5 17 18 19 20.

       --test-rate<n>
              Sets  the  number  of  packets  to pass before causing a reordering test.  Default is 100.  Has no
              effect if test-type is zero.  The result of test types 2 and 3 are undefined if this value is less
              than ten.

       --missing-window<n>
              Enable 'missing window' validation and set packet tolerance (300=default, 6000=recommended).

       --version
              Display version.

BEZEQ_ISRAEL
              modifies packets to interoperate with Orckit ADSL modems on the BEZEQ network in Israel.

       When PPTP is used in conjunction with  a  default  route  on  top  of  the  tunnel  (or  just  any  route
       encompassing  the  PPTP  server),  the mechanics of routing would cause the PPTP packets themselves to be
       routed over the tunnel. This would result in an encapsulation loop, destroying connectivity.

       pptp by default works around this by looking up  the  route  towards  the  PPTP  server  at  startup  and
       configures  a  host  route  with  that  data.  This essentially "freezes" routing for PPTP packets at the
       startup configuration. This behaviour can be disabled with --nohostroute if undesired  (like  when  using
       --rtmark to implement policy routing).

       NB: the route added by pptp is currently not deleted at exit!

pppd(8)

       Documentation in /usr/share/doc/pptp-linux

       The pptp process collects statistics when sending and receiving GRE packets.  They  are  intended  to  be
       useful for debugging poor PPTP performance and for general monitoring of link quality. The statistics are
       cumulative since the pptp process was started.

       The  statistics can be viewed by sending a SIGUSR1 signal to the "GRE-to-PPP Gateway" process, which will
       cause it to dump them to the system logs  (at  the  LOG_NOTICE  level).  A  better  way  to  present  the
       statistics to applications is being sought (e.g. SNMP?).

       The following statistics are collected at the time of writing (April 2003):

       rxaccepted
              the number of GRE packets successfully passed to PPP

       rxlost
              the number of packets never received, and presumed lost in the network

       rxunderwin
              the number of packets which were duplicates or had old sequence numbers (this might be caused by a
              packet-reordering network if your reordering timeout is set too low)

       rxoverwin
              the number of packets which were too far ahead in the sequence to be reordered (might be caused by
              loss of more than 300 packets in a row)

       rxbuffered
              the  number  of  packets  which  were  slightly  ahead  of  sequence, and were either buffered for
              reordering, or if buffering is disabled,  accepted  immediately  (resulting  in  the  intermediate
              packets being discarded).

       rxOSerrors
              the number of times where the operating system reported an error when we tried to read a packet

       rxtruncated
              the  number  of  times  we  received a packet which was shorter than the length implied by the GRE
              header

       rxinvalid
              the number of times we received a packet which had invalid or unsupported flags set in the header,
              wrong version, or wrong protocol.

       rxacks
              the number of pure acknowledgements  received  (without  data).  Too  many  of  these  will  waste
              bandwidth, and might be solved by tuning the remote host.

       txsent
              the number of GRE packets sent with data

       txfailed
              the number of packets we tried to send, but the OS reported an error

       txshort
              the number of times the OS would not let us write a complete packet

       txacks
              the number of times we sent a pure ack, without data

       txoversize
              the number of times we couldn't send a packet because it was over PACKET_MAX bytes long

       roundtrip
              the estimated round-trip time in milliseconds

pptp<pptp-server-IP><pptp-options>[ppp-options]...