pptp(8)

NAME
pptp - Point-to-Point Tunneling Protocol daemon

SYNOPSIS
pptp hostname [--version] [--phone number] [--nolaunchpppd] [--quirks quirk] [--debug] [--sync] [--timeout secs] [--nobuffer] [--idle-wait time] [--max-echo-wait time] [--logstring name] [--localbind addr] [--loglevel level] [ppp options]

DESCRIPTION
pptp manages a virtual private network (VPN) connection using Microsoft PPTP protocols using IP GRE tunneling protocols. pptp uses ppp(8) on a pseudo-tty to negotiate the connection with MS-CHAP authentication.

Because pptp uses GRE, the net.inet.gre.allow sysctl needs to be enabled. pptp will automatically try to enable this sysctl on startup.

The hostname parameter specifies which host should be contacted as the PPTP server.

[ppp options] are passed on to ppp(8) and typically include a remote username or a file containing options.

pptp must be run as root.

pptp accepts the following options:

--version
    Display version number and exit.

--phone number
    Pass number to remote host as phone number.

--nolaunchpppd
    Do not launch a ppp daemon, for use as a ppp daemon pty.

--quirks quirk
    Some ADSL providers and some ADSL hardware are buggy or not conforming to the RFC, and require special handling. To this end, pptp supports a 'quirks' mechanism. Currently, only '--quirks BEZEQ_ISRAEL' is defined, for connecting to Bezeq (the Israeli phone company) ADSL service. Only some of the equipment used by Bezeq needs this option, but even the equipment that does not need it works fine with it.

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

--sync
    Enable Synchronous HDLC. ppp(8) must use it, too.

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

--nobuffer
    Disable packet buffering and reordering completely

--idle-wait secs
    Time to wait before sending echo request.

--max-echo-wait secs
    Time to wait before giving up on lack of reply. This option seems to be unimplemented, because the flag can be set but is never evaluated (look at pptp_ctrl.c) — dead, unused code?

--logstring name
    Use name instead of “anon” in syslog messages.

--localbind addr
    Bind to specified IP address instead of wildcard.

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

EXAMPLES

  PPTP on a stand-alone VPN client
This example assumes that you want to use pptp to connect to a VPN and use the VPN connection as your default route. Let us assume that the PPTP server is called pptp.example.net.

First, edit /etc/ppp/ppp.conf and add an entry for the VPN connection. See ppp(8) for details on the format of this file.

      vpn:
    	set device "!/usr/local/sbin/pptp --nolaunchpppd pptp.example.net"
    	set authname User
    	set authkey MySecret
    	set mppe 128 stateless

Next, you need to configure routing in /etc/ppp/ppp.linkup:

      vpn:
        add! default HISADDR

If pptp.example.net does not reside on the local network, we have to add a host route pointing to pptp.example.net in order to avoid a chicken-and-egg problem once the default route is set to the VPN tunnel. Assuming the standard default route is 192.168.1.1:

/etc/ppp/ppp.linkup:

      vpn:
        add pptp.example.net 192.168.1.1
        add! default HISADDR

If your default route is not fixed, for example if you connect to the VPN from many different networks while on the road, use a script to figure out the current default route and add the host route to the VPN gateway. For example:

/etc/ppp/vpn-default-route.sh:

    	#!/bin/sh
            gw=`netstat -rn -f inet | grep ^default | awk '{print $2};'`
            /sbin/route add -host pptp.example.net ${gw}

Call the script from /etc/ppp/ppp.linkup:

      vpn:
        ! sh /etc/ppp/vpn-default-route.sh
        add default HISADDR

    Make sure the changes to the routing table are reversed in
    /etc/ppp/ppp.linkdown:

          vpn:
            delete pptp.example.net

    Restoring the previous default route in
    /etc/ppp/ppp.linkdown
    is left as an exercise for the reader. On a laptop it is usually
    enough to issue a DHCP request to restore the routing table
    after the VPN connection is terminated.

    Connect by running:
        ppp -ddial vpn

    To terminate the connection, kill the ppp process. It creates a PID
    file in /var/run/tunX.pid, where X is the number of the tun device used.

  PPTP on a router
This example assumes that you want to configure a router running OpenBSD to provide PPTP VPN access to a remote network for all hosts on your internal network.

Let us assume that the VPN server is called pptp.example.net, and that the default route of our OpenBSD box is 192.168.1.1. The remote network shall be 10.42.0.0/16; we want all traffic to this network to go through the VPN tunnel.

First, edit /etc/ppp/ppp.conf and add an entry for the VPN connection. See ppp(8) for details on the format of this file.

      default:
    	set log Phase Chat LCP IPCP CCP tun command
      vpn:
    	set device "!/usr/local/sbin/pptp --nolaunchpppd pptp.example.net"
    	set authname User
    	set authkey MySecret
    	set mppe 128 stateless

Next, you need to configure routing in /etc/ppp/ppp.linkup. We also load pf(4) anchors for the vpn interface here. More on that later.

/etc/ppp/ppp.linkup:

      vpn:
        add 10.42.0.0/16 HISADDR
        ! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"

If pptp.example.net resides inside 10.42.0.0/16, we have to add a host route pointing to pptp.example.net in order to avoid a chicken-and-egg problem once packets to 10.42.0.0/16 are routed through the tunnel.

/etc/ppp/ppp.linkup:

      vpn:
        add pptp.example.net 192.168.1.1
        add 10.42.0.0/16 HISADDR
        ! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"

If your default route is not fixed, for example if your ISP does not always assign the same gateway to you, use a script to figure out the current default route and add the host route to the VPN gateway. For example:

/etc/ppp/vpn-default-route.sh:

    	#!/bin/sh
            gw=`netstat -rn -f inet | grep ^default | awk '{print $2};'`
            /sbin/route add -host pptp.example.net ${gw}

Call the script from /etc/ppp/ppp.linkup:

      vpn:
        ! sh /etc/ppp/vpn-default-route.sh
        add 10.42.0.0/16 HISADDR
        ! sh -c "/sbin/pfctl -a vpn -f /etc/pf.conf.vpn"

    Make sure the changes to the routing table are
    reversed when the VPN connection drops:

    /etc/ppp/ppp.linkdown:

          vpn:
            ! sh -c "/sbin/pfctl -a vpn -F all"
            delete 10.42.0.0/16
            delete pptp.example.net

    To make
    pf(4)
    aware of the vpn anchors, put these lines into the
    NAT and Filter sections of
    /etc/pf.conf,
    respectively:

          nat-anchor	vpn
          anchor	vpn

    See
    pf.conf(5)
    for details on the format of this file.

    Now define vpn anchor rules in
    /etc/pf.conf.vpn,
    for example:

          int_if=xl0
          vpn_if=tun0
          # NAT is of course optional. The remote network needs
          # a route to our network as well if we don't do NAT.
          nat on $vpn_if from $int_if:network to any -> ($vpn_if)
          block drop on $vpn_if
          pass out on $vpn_if
          # Allow ping from remote, and explicitly make sure our replies are
          # routed back through the tunnel.
          pass in on $vpn_if reply-to ($vpn_if pptp.example.net) \
        	inet proto icmp icmp-type echoreq keep state
          # Same for ssh.
          pass in on $vpn_if reply-to ($vpn_if pptp.example.net) proto tcp \
        	from any to ($vpn_if) port ssh flags S/SA keep state

    Connect by running:
        ppp -unit0 -ddial vpn

    The -unit0 option makes sure ppp configures tun0 as the VPN
    connection end point, and not some other tun device.
    The packet filter rules configured above assume tun0 as the
    VPN connection end point.

    To terminate the connection, kill the ppp process. It creates a PID
    file in /var/run/tunX.pid, where X is the number of the tun device used.

FILES
/var/run/pptp/<ip-address> is created as a socket. It is used for communicating with an existing PPTP call manager for a given remote server host.

CAVEATS
The PPTP protocol is insecure.

SEE ALSO
ppp(8), gre(4), pf(4), pf.conf(5), /usr/local/share/doc/pptp/PROTOCOL-SECURITY.

HISTORY
This man page appeared first in NetBSD 's pptp package.

AUTHORS
Stefan Sperling <stsp@openbsd.org> C. Scott Ananian <cananian@alumni.princeton.edu>, John Kohl <jtk@NetBSD.org> (patches and original man page).