SourceForge Logo
opensource.hp.com Link to Linux and HP web site
project
 overview
 license
 getting started
 features
 try it
 download
 links
documentation
 index
 debian 3.0
 mandrake 9.0
 red hat 9.0
 red hat 8.0
 red hat 7.3
 red hat 6.2
 diagnosis
 support faq
 diagrams
 routing
team
 developers
 cvs
 contact us
 

PPTP Client


Diagnosis HOWTO

by James Cameron
5th June 2003

You're probably here because you have a problem getting PPTP Client to work. There are many reasons why it can fail. Other people may have encountered the problem you have.

This HOWTO is in two parts; common problems and a fault tree. The common problems part has error messages along with solutions. The fault tree part is a list of things to check in order.

When the PPTP Client fails, it will display an error message. Search for the message in this page. For some error messages, more detail will need to be gathered. This is done by enabling debug logging.


Contents


Conventions

Conventions used in this document:

italic text, a program name or option keyword

monospaced text, a file name

blue background, error messages or log output

green background, commands to be entered

red background, quotation

yellow background with black vertical "change bar" on right hand side, text changed in this revision (or the last month)  


Common Problems


  1. pptp-command: command not found

    Symptom: when trying to start pptp or pptp-command as a non-root user, this message appears:

    pptp-command: command not found

    Diagnosis: the pptp-command program is not in your PATH, because pptp requires root to be able to create a raw socket for GRE packet transmission.

    Solution 1: Be root first.

    Solution 2: Install pptp-php-gtk, and start it by typing pptpconfig. If you are not root, you will be prompted for the root password. You may find it much easier to configure than pptp-command.

    2003-05-02
     

    Solution 3: Use the new activation technique. This causes pppd to start pptp attached to a psuedo-tty, rather than the old technique which was to have pptp start pppd. Since pppd is already designed to be started by non-root users, it is better to use this new technique.

    1. Make sure you are using pptp-client 1.1.0 or later.

    2. As root, configure the tunnel with pptp-command, test it, but then stop using pptp-command,

    3. edit the /etc/ppp/peers/tunnel file, and add a line as follows:

      pty "pptp x.x.x.x --nolaunchpppd"

      where tunnel is the name of the tunnel configuration you created, and x.x.x.x is the IP address or host name of the PPTP Server.

    4. Make pptp setuid root:

      # chmod u+s `which pptp`

    5. Test that a pppd command line can be used to start the tunnel:

      # pppd call tunnel

      where tunnel is the name of the tunnel configuration file. pppd knows to look in /etc/ppp/peers for the file.

      If the tunnel does not start, enable debug logging, and try the pppd command again.

    6. Return to non-root user mode, and then use a normal GUI or console utilities (e.g. pon and poff) to start or stop the pppd connection named 'tunnel'.

      # pon tunnel


  2. ppp <= 2.3.15 conflicts with kernel

    Symptom: when installing ppp-mppe-2.4.0-4.*.rpm on Red Hat 7.2 or later, this message appears:

    error: failed dependencies:
    ppp <= 2.3.15 conflicts with kernel-2.4.7-10

    On Red Hat 7.3, the kernel version is usually 2.4.18-3.

    Diagnosis: the 2.4.0-4 ppp-mppe package provides a ppp package without a version. The newer Red Hat kernel packages require a specific version, and so the conflict occurs. Since pptp-linux 1.1.0 there is no longer a dependency on ppp-mppe, as many people don't need to interoperate with a Microsoft VPN Server.

    Solution 1: use the kernelmod instructions which are part of the Red Hat 9.0 HOWTO. This alleviates the problem.

    2003-05-02
     

    Solution 2: Install the package with --nodeps.

    rpm -Uvh --nodeps ppp-mppe-2.4.0-4.i386.rpm

    The installation script should tell you that you will have to build the kernel module yourself. Follow the instructions provided with the notice to build the kernel module, then follow the instructions provided from the kernel module build to install the new module. Note that the kernel-sources package for your kernel needs to be installed to complete the build.

    On Red Hat 7.3, edit /etc/modules.conf and add these lines:

    alias char-major-108 ppp_generic
    alias ppp-compress-18 mppe


  3. pppd cannot load kernel module ppp_generic

    Symptom: when starting PPTP Client on Red Hat 7.2 or 7.3, the pppd process cannot locate the appropriate module.

    modprobe: modprobe: Can't locate module char-major-108
    /usr/sbin/pppd: This system lacks kernel support for PPP. This could be because the PPP kernel module could not be loaded, or because PPP was not included in the kernel configuration.

    Diagnosis: the 2.4.0-4 ppp-mppe package adds entries to /etc/modules.conf that work only for Red Hat 6.2.

    Solution 1: use the kernelmod instructions which are part of the Red Hat 9.0 HOWTO. This alleviates the problem.

    2003-05-02
     

    Solution 2: Edit the /etc/modules.conf file and change the alias char-major-108 ppp to alias char-major-108 ppp_generic.


  4. connect: Connection Refused

    Symptom: on starting pptp, three messages appear, followed by a delay:

    warn[open_inetsock:pptp_callmgr.c:305]: connect: Connection refused
    fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x
    fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256

    Diagnosis: the host that you provided has refused connection.

    Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.


  5. connect: Network is unreachable

    Symptom: on starting pptp, three messages appear:

    warn[open_inetsock:pptp_callmgr.c:305]: connect: Network is unreachable
    fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x
    fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256

    Diagnosis: the host that you provided cannot be reached via the network. This is usually caused by not having an active internet connection at all.

    Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.


  6. connect: No route to host

    Symptom: on starting pptp, three messages appear:

    warn[open_inetsock:pptp_callmgr.c:305]: connect: No route to host
    fatal[callmgr_main:pptp_callmgr.c:128]: Could not open control connection to x.x.x.x
    fatal[open_callmgr:pptp.c:278]: Call manager exited with error 256

    Diagnosis: the host that you provided cannot be reached via the network.

    Solution: check the IP address or name of the PPTP Server, and check that the PPTP Server is running properly. Work through the Fault Tree from the top.


  7. short read (4294967295): Input/output error

    Symptom: the following messages appear before the tunnel is established:

    log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established.
    log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0).
    log[decaps_hdlc:pptp_gre.c:129]: short read (4294967295): Input/output error
    log[callmgr_main:pptp_callmgr.c:245]: Closing connection
    log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection
    log[call_callback:pptp_callmgr.c:88]: Closing connection

    Diagnosis: pppd was started by pptp but was unable to operate, and so terminated quickly. pptp tried to read data from pppd but found none. There are many reasons why pppd could have failed, but the most likely are configuration file errors.

    Solution: Enable debug logging and check to see why pppd failed. Search this HOWTO for those messages.


  8. short read (4294967295): Protocol not available

    Symptom: the following messages appear before the tunnel is established:

    log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:580]: Client connection established.
    log[pptp_dispatch_ctrl_packet:pptp_ctrl.c:708]: Outgoing call established (call ID 0, peer's call ID 0).
    log[decaps_gre:pptp_gre.c:215]: short read (4294967295): Protocol not available
    log[callmgr_main:pptp_callmgr.c:245]: Closing connection
    log[pptp_conn_close:pptp_ctrl.c:307]: Closing PPTP connection
    log[call_callback:pptp_callmgr.c:88]: Closing connection

    Diagnosis: usually caused by the client not binding to the GRE socket early enough during the connection sequence. The first GRE packet from the server causes an ICMP protocol unreachable reply. This happens more frequently on high speed connections.

    Workaround: load the ip_gre module. This prevents the ICMP protocol unreachable reply from being generated.

    # modprobe ip_gre

    Solution: upgrade to pptp-linux 1.2.0, which binds the GRE socket prior to calling the server. Loading the ip_gre module should not be needed.

    2003-05-02
     


  9. Operation not permitted

    Symptom: write to the GRE socket fails with EPERM.

    Diagnosis: iptables rules (such as for a firewall configuration) do not allow the interface to emit GRE packets.

    Solution: locate the rule that prevents the write, or add a rule to cover it, and retry the tunnel.


  10. write: warning: Input/output error

    Symptom: when using pptp started as a psuedo-tty from within pppd, the following messages appear before connection is established:

    write: warning: Input/output error (5)
    Modem hangup

    Diagnosis: pptp is not running at the time pppd writes to the psuedo-tty. This may be because you have no pptp program, or it may have failed. Enabling debug logging would show just one message, an LCP write, being sent prior to the write warning.

    Solution: check that the pptp program is present, check that the --nolaunchpppd option is being used, and check the messages log for messages emitted by pptp.


  11. CHAP authentication failed

    The usual cause of this is entering the wrong password. Passwords which contain odd characters, like hash (#) may need to be quoted in the chap-secrets file.

    Also see below.

  12. failed to authenticate ourselves to peer

    Symptom: pppd fails during a connection attempt and issues this message:

    sent [CHAP Response id=0x0 <...>, name = "domain\\\\username"]
    rcvd [LCP EchoRep id=0x0 magic=0x15973814]
    rcvd [CHAP Failure id=0x0 "E=691 R=1 C=... V=3"]
    Remote message: E=691 R=1 C=... V=3
    CHAP authentication failed
    sent [LCP TermReq id=0x3 "Failed to authenticate ourselves to peer"]
    rcvd [LCP TermAck id=0x3 "Failed to authenticate ourselves to peer"]

    Diagnosis: four slashes have been used instead of two between the domain name and the username. This is a common error, due to the escaping and quoting rules of the shell versus the pppd options file.

    Solution: remove two of the slashes.


  13. none of the available passwords would let it use an IP address

    Symptom: pppd fails during a connection attempt and issues this message:

    The remote system (hostname) is required to authenticate itself
    but I couldn't find any suitable secret (password) for it to use to do so.
    (None of the available passwords would let it use an IP address.)

    Note the last line. If this is not present, read the next entry.

    Diagnosis: No IP address listed in chap-secrets file. pptp-command adds entries to the file without an IP address, and the manual page for pppd says that this means no IP address will be considered valid. Not all versions of pppd require this.

    Solution: Adjust the chap-secrets file to add an asterisk as the address, which is the fourth field.


  14. remote system is required to authenticate itself

    Symptom: pppd fails during a connection attempt and issues this message:

    The remote system (hostname) is required to authenticate itself
    but I couldn't find any suitable secret (password) for it to use to do so.

    If after this it says that none of the available passwords would let it use an IP address, read the previous entry.

    Diagnosis 1: While normally the PPTP Server will require authentication from your client, your pppd configuration files can tell your client to require authentication from the PPTP Server. The message shows there is insufficient information to achieve this, and so pppd stops.

    Solution 1: Usually it is not necessary to have the PPTP Server authenticate in this way. Make sure that that noauth option is in the options file, or given to pppd via the command line.

    Diagnosis 2: You may have rebuilt the kernel after installing the modules for the PPTP Client. During "make modules_install", you will have overwritten the misc/mppe.o and kernel/drivers/net/ppp_generic.o modules.

    Solution 2: reinstall the two modules.

    We believe there may be other causes of this error. Please write to the mailing list if this solution does not fix your problem, so that we can work together to improve this HOWTO.


  15. LCP: No network protocols running

    See below.

  16. LCP: timeout sending Config-Requests

    This is a general error condition that is common to a number of causes. It means that pppd did not receive any LCP configuration requests from the PPTP Server, or was unable to agree on LCP parameters. Enable debug logging, try the connection again, and look at messages just prior to this message.

    There are many causes for the timeout error:

    Use tcpdump to check the flow of GRE packets.

    No GRE received by PPTP Client
    No GRE transmitted by PPTP Server
    Invalid GRE packets transmitted by server
    No GRE packets transmitted by client
    Invalid GRE packets transmitted by client

  17. LCP ConfRej <auth chap 81>

    Symptom: you are using PPP-MPPE 2.4.x and logs contain this sequence:

    rcvd [LCP ConfReq id=0x0 <auth chap 81> <magic 0x7a73> <pcomp> <accomp>]
    sent [LCP ConfRej id=0x0 <auth chap 81>

    See next item below.

  18. LCP ConfRej <auth chap MS-v2>

    Symptom: you are using PPP 2.4.2 and logs contain this sequence:

    rcvd [LCP ConfReq id=0x0 <auth chap MS-v2> <magic 0x7a73> <pcomp> <accomp>]
    sent [LCP ConfRej id=0x0 <auth chap MS-v2>

    Diagnosis: your pppd is refusing to perform MS-CHAP-V2 authentication. The PPTP Server requires it, and so it terminates the connection. The known causes are:

    • pppd could not find a matching entry in the chap-secrets file,
    • pppd was built without MS-CHAP-V2 support (uncommon).

    The search in the chap-secrets file uses the name and remotename options given to pppd. The name is usually the authentication domain and username. The remotename is usually PPTP, or the name of the tunnel.

    The chap-secrets file is a series of lines with blank separated fields. The file is searched for a line where:

    • the first field matches the local name option value (e.g. domain\\username),
    • the second field matches the remotename option value (e.g. tunnelname or PPTP), and
    • the fourth field contains a valid IP address or asterisk.

    Any spaces or special characters in the local name, password, or remote name must be properly quoted. See man pppd section authentication for more details.

    Solution: fix the chap-secrets file or the pppd options so that they match.

    2003-05-30
     


  19. CCP: timeout sending Config-Requests

    The pppd did not complete CCP configuration within the timeout period. Usually caused by a conflict between the client and the PPTP Server. Enable debug logging, try the connection again, and look at messages just prior to this message.

    See below for the most likely cause.

  20. CCP ConfNak <mppe 0 0 0 0>

    Symptom: debug logs contain this sequence:

    sent [CCP ConfReq id=0x5]
    rcvd [CCP ConfNak id=0x5 <mppe 0 0 0 0>]
    sent [CCP ConfReq id=0x6]
    rcvd [CCP ConfNak id=0x6 <mppe 0 0 0 0>]
    sent [CCP ConfReq id=0xa]
    rcvd [CCP TermReq id=0x3 00 00 02 dc]
    sent [CCP TermAck id=0x3]
    sent [LCP EchoReq id=0x1
    CCP: timeout sending Config-Requests
    sent [LCP EchoReq id=0x2
    No response to 4 echo-requests
    Serial link appears to be disconnected.
    sent [LCP TermReq id=0x3 "Peer not responding"]

    Diagnosis: your pppd is refusing to accept MPPE encryption, despite passing through MSCHAP authentication. The PPTP Server requires MPPE, and so it terminates the connection.

    Solution: make sure the MPPE module loads successfully. Prove this using the MPPE step in the Fault Tree.


  21. LCP terminated by peer (peer refused to authenticate)

    Your pppd could not negotiate authentication. Enable debug logging, try the connection again, and look for rejection packets just prior to this message. Decide what to do based on the rejection packets.


  22. LCP terminated by peer (garbled text)

    Your pppd could not negotiate encryption. Enable debug logging, try the connection again, and look for rejection packets just prior to this message. Decide what to do based on the rejection packets.

    See the next two sections below for the most likely causes.

  23. EAP Response ... LCP TermReq

    Symptom: an LCP TermReq occurs immediately after an EAP Response, as per this example log:

    rcvd [EAP Request id=0x0 Identity <No message>]
    sent [EAP Response id=0x0 Identity <Name "username">]
    rcvd [LCP TermReq id=0x3 0e a3 45 cf 00 3c cd 74 00 00 02 89]
    LCP terminated by peer (^NM-#EM-O^@

    Diagnosis: this may be an indication that EAP authentication failed.

    Solution: either correct the cause of the authentication failure, or direct the client to refuse EAP authentication by adding refuse-eap to the list of pppd options.

    2003-05-26
     

  24. CCP terminated by peer

    Compression negotiation has failed. Occurs after a CCP ConfRej. See below for likely cause.

    If that doesn't fix it, enable debug logging, try the connection again, and look for rejection packets just prior to this message. Decide what to do based on the rejection packets.

    2003-05-26
     

  25. CCP ConfRej <mppe 1 0 0 40>

    Symptom: logs contain this sequence:

    sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <compress VJ 0f 01>]
    sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
    rcvd [CCP ConfReq id=0x3 <mppe 1 0 0 e1>]
    sent [CCP ConfNak id=0x3 <mppe 1 0 0 60>]
    rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
    sent [CCP ConfReq id=0x2]
    rcvd [CCP ConfReq id=0x5 <mppe 1 0 0 40>]
    sent [CCP ConfRej id=0x5 <mppe 1 0 0 40>]
    rcvd [CCP ConfNak id=0x2 <mppe 1 0 0 40>]
    sent [CCP ConfReq id=0x3]
    rcvd [LCP TermReq id=0x6 "#\37777777776U\37777777621\000<..."]
    LCP terminated by peer (#M-~UM-^Q^@<M-Mt^@^@^BM-f)
    sent [LCP TermAck id=0x6]

    Diagnosis 1: your pppd is refusing to accept the level of MPPE encryption required by the PPTP Server. The PPTP Server insists on that level, and so it terminates the connection.

    Solution 1: make sure the require-mppe option is provided to the pppd command, such as in the options file. For versions of pppd prior to and including 2.4.0, provide the options mppe-40, mppe-128 and mppe-stateless. See also Why are the pppd options different?.

    Make sure the MPPE module loads successfully. Prove this using the MPPE step in the Fault Tree.

    Diagnosis 2: You may have rebuilt the kernel after installing the modules for the PPTP Client. During "make modules_install", you will have overwritten the misc/mppe.o and kernel/drivers/net/ppp_generic.o modules.

    Solution 2: reinstall the two modules.


  26. CCP: No compression negotiated

    See below.

  27. CCP ConfRej <deflate 15>

    Symptom: debug logs contain this sequence:

    sent [CCP ConfReq id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
    rcvd [CCP ConfRej id=0x1 <deflate 15> <deflate(old#) 15> <bsd v1 15>]
    sent [CCP ConfReq id=0x2]
    sent [CCP ConfReq id=0x2]
    rcvd [CCP TermAck id=0x2]
    sent [CCP TermReq id=0x3"No compression negotiated"]
    rcvd [CCP TermAck id=0x3]

    Diagnosis: your pppd is suggesting only deflate and bsdcomp compression options, and not MPPE. The PPTP Server rejects the suggestions and disconnects.

    Solution: make sure the require-mppe option is provided to the pppd command, such as in the options file. For versions of pppd prior to and including 2.4.0, provide the options mppe-40, mppe-128 and mppe-stateless. See also Why are the pppd options different?. Make sure the nobsdcomp and nodeflate options are provided, so that pppd does not suggest them.


  28. LCP TermReq id=0x3 "MPPE required but not available"

    Symptom: debug logs contain this sequence:

    MPPE required, but kernel has no support.
    sent [LCP TermReq id=0x3 "MPPE required but not available"]

    See below.

    2003-06-05
     

  29. MPPE required, but kernel has no support.

    Symptom: logs contain this sequence:

    MPPE required, but kernel has no support.

    Diagnosis: either the kernel has no MPPE support, or this version of pppd is incompatible with the MPPE kernel module version you used. The most likely cause is using PPP 2.4.2 or later on a kernel that has an MPPE module built for PPP-MPPE 2.4.0 or 2.4.1.

    See also Why are the pppd options different?

    Solution: Ensure you have MPPE support in the kernel. Prove this using the MPPE in kernel step in the Fault Tree.

    Ensure the versions of PPP and PPP's MPPE kernel support match.

    To identify the version of PPP, use the command:

    # pppd --version

    Identifying the version of PPP's MPPE kernel module is not as straightforward. It is best to know where it came from originally. Alternatively, use the command:

    # modinfo ppp_mppe

    to find whether the module information says the license is "BSD without advertisement clause". If it is, then it is most likely the PPP 2.4.2 module.

    If the module name is mppe.o, then it is most likely the PPP-MPPE 2.4.0 module.

    If the kernel package or module package significantly predates the release of the version of PPP that you are running, then a version mismatch is even more likely.

    2003-06-05
     


  30. Unsupported protocol 0x2145 received

    Problem: the PPTP Server is trying to use Microsoft Point-to-Point Compression (MPPC), and your local pppd does not support it. Most frequently seen with Watchguard Firebox product.

    Solution 1: add nopcomp to the options. (noaccomp may also be required, though for some people it stops it working.)

    Solution 2: turn off MPPC at the PPTP Server.

    Solution 3: add MPPC support to your system, if it is available.

    MPPC is a patent-encumbered compression method.

    References:

    1. Cisco's description of MPPC, showing the protocol code.

    2. Mail on [pptp-server] mailing list saying that you don't need MPPC anyway, and nobody has written it for Linux. [link no longer valid]

    3. FreeBSD supports it, somehow. However investigations by Frank show the code is not present.

    4. A book mentions ppp-mppc in contents listing, implying existence.

    5. Mail saying that MPPC would need licensing from STAC Electronics.

    6. The ppp package README confirms the above, where it says:

      Compression methods.
      ********************

      This package supports two packet compression methods: Deflate and BSD-Compress. Other compression methods which are in common use include Predictor, LZS, and MPPC. These methods are not supported for two reasons - they are patent-encumbered, and they cause some packets to expand slightly, which pppd doesn't currently allow for. BSD-Compress is also patent-encumbered (its inclusion in this package can be considered a historical anomaly :-) but it doesn't ever expand packets. Neither does Deflate, which uses the same algorithm as gzip.

    7. Jan Dubiec's implementation of MPPC, which may be a violation of the patent but we've not checked.


  31. Protocol-Reject for unsupported protocol 0x????

    See below.

  32. LCP ProtRej id=0x??

    Symptom: connection is established, but after MPPE is negotiated no data transfer happens, and the debug logs contain this sequence:

    rcvd [LCP ProtRej id=0x70 59 ae 22 41 d5 15 51 fc 50 3a 4b 21 ...]
    rcvd [LCP ProtRej id=0x71 b5 a7 dc 7d 99 fd eb ec 92 5e 0b b6 ...]
    rcvd [LCP ProtRej id=0x72 e9 62 fb 15 c1 b5 e0 b3 92 22 46 1e ...]
    rcvd [LCP ProtRej id=0x73 19 3d 51 49 25 4f 25 f9 98 0d 1f 70 ...]
    rcvd [LCP ProtRej id=0x74 cc 09 4e a5 62 59 92 cf 88 8d 4b 99 ...]

    The important pattern appears to be the incrementing first byte.

    Diagnosis: the PPTP Server has negotiated 40-bit MPPE, but the client has negotiated 128-bit MPPE. The protocol reject messages are triggered by the pppd reading the improperly decoded data stream. Cause of this situation is not known, but it may be due to the PPTP Server being configured for 40-bit encryption only.

    Solution: add nomppe-128 to the options given to pppd.


  33. Connection closes after 60 seconds

    Symptom: logs contain this sequence:

    bad bytes thrown away
    Outgoing call established
    [60 second delay]
    Closing PPTP connection

    Diagnosis: the PPTP Server is not conforming to RFC2637, which states that the reserved0 field in the header MUST be zero. It was fixed in 1.1.0-1, thanks to Rein Klazes.

    Solution: upgrade to pptp-linux-1.1.0-1 or later.


  34. LCP EchoReq without LCP EchoRep

    Symptom: connection is established but no data transfer happens, ifconfig shows large amounts of data transmitted on PPTP tunnel, tcpdump shows many transmitted packets, the connection is closed after one minute, and logs contain this sequence:

    rcvd [LCP EchoReq id=0x1
    sent [LCP EchoRep id=0x1
    sent [LCP EchoReq id=0x1
    rcvd [LCP EchoReq id=0x2
    sent [LCP EchoRep id=0x2
    sent [LCP EchoReq id=0x2

    which indicates that echo requests from the server are being received by the client, which issues an echo reply, but that echo requests from the client are not generating echo replies from the server.

    Diagnosis: the route to the PPTP Server has changed to include the tunnel itself, and packets are being looped. Packets sent through the VPN are being encapsulated in PPP over GRE, and then sent through the same interface again.

    See our diagram that explains this further. See our Routing HOWTO for more information about routing.

    Solution: Examine the routing table using netstat -rn before and after the tunnel becomes active. Determine why the route to the PPTP Server is via the tunnel interface. The reasons may be:

    1. the defaultroute option was used,

    2. distribution specific or local interface-up scripts changed the route, or

    3. the PPTP Server may have given its own IP address for the new interface (compare "remote IP address" in the debug logs with the IP address you give to pptp).

    If defaultroute is in the options given to pppd remove it, and use other means to provide routes through the tunnel interface.

    If scripts are adding or changing routes, fix them.

    If the PPTP Server is providing its own IP address as the tunnel remote IP address, try one of the following:

    1. add a static route to the PPTP Server via your usual default gateway, for example;

      route add -host x.x.x.x/32 gw y.y.y.y dev nnn0

      where x.x.x.x is the IP address of the PPTP Server, y.y.y.y is the IP address of your usual default gateway, and nnn0 is the name of the network interface through which the gateway is contacted.

    2. request a more appropriate address by adding an option such as :10.0.1.1, where 10.0.1.1 is the address to be adopted, (the PPTP server may be configured to refuse the request, or may not be capable of it)

    3. use the iptables and ip commands to direct the tunnel packets away from the tunnel interface, see our Routing HOWTO for more detail,

    4. ask the PPTP Server administrator to change the configuration to use another remote address.


  35. Not enough space to encrypt packet

    Problem: following message appears in pppd logs

    Not enough space to encrypt packet: 1004<1004+4!

    Solution: patch ppp_generic.c using the patches in this project's CVS repository.

    The patches are in mppe/kernel/kernel, and are ppp_generic.ccp_max_option_length.patch and ppp_generic.header_length.patch.

    Carsten Grammes found that the SuSE 8 kernel (2.4.18-4GB) has MPPE support, but shows this problem. The patches above solved the problem. [2002-08-23]


  36. Connections via tunnel freeze

    Are your connections from the PPTP Client or from another machine on your network?

    Problem: TCP connections via the tunnel freeze once they attempt to transfer large amounts of data.

    Diagnosis: MTU in use may exceed capability of the tunnel.

    Solution: verify that the MTU and MRU parameters are given as options to the pppd program, either in the peers file for the tunnel, in the options file, or on the command line. The parameters known to work are:

    mtu 1000
    mru 1000

    (However recent tests have shown an MTU of 1500 also seems to work fine, on Linux 2.4.18.)

    Problem: TCP connections using the PPTP Client host as a hop in the route (such as via normal routing, NAT or IP masquerading) freeze once they attempt to transfer large amounts of data.

    Diagnosis: Path MTU Discovery may not be working, due to hosts on the route refusing to forward ICMP responses.

    Solution: if using Linux 2.2, reduce the MTU on all hosts using the PPTP Client host as their route. If using Linux 2.4, add the following iptables rule:

    iptables --append FORWARD --protocol tcp \
    --tcp-flags SYN,RST SYN --jump TCPMSS --clamp-mss-to-pmtu

    For more information, see section 15.7, Circumventing Path MTU Discovery issues with MSS Clamping (for ADSL, cable, PPPoE & PPtP users) in the Linux Advanced Routing & Traffic Control HOWTO.


  37. Connections via tunnel fail or timeout

    Problem: tunnel connects, ping fails to other end of tunnel, and transmit packet and byte counts as shown by ifconfig for the tunnel interface are rapidly increasing.

    Diagnosis: an IP loop may exist.

    Solution: see the IP loop section.

    Problem: tunnel connects, ping fails to other end of tunnel, and CPU load is very high.

    Diagnosis: an IP loop may exist.

    Solution: see the IP loop section.

    Problem: tunnel connects, ping works to other end of the tunnel (remote IP address as shown in debug log), but cannot ping beyond that point, and connections to hosts at the other end fail or timeout.

    Solution: this is a routing problem, not a tunnel problem. Check out the PPTP Client Routing HOWTO.


  38. insecure dependency

    The pptp-command script is using a Perl feature to enhance software security design, but newer Perl versions are more exacting.

    Problem: pptp-command fails with a message about an insecure dependency and the -T switch.

    Solution 1: Install pptp-php-gtk, and start it by typing pptpconfig. If you are not root, you will be prompted for the root password. You may find it much easier to configure than pptp-command.

    Solution 2: upgrade to 1.2.0 or later of pptp-linux. If the problem continues, upgrade to the latest pptp-command from CVS.

    2003-05-02
     

    Workaround: remove the -T switch from the top of the pptp-command file. Report the version of Perl, and the exact text of the error message, so we can fix it.


  39. WARNING: the line: contains unsafe characters

    Problem: pptp-command fails to enter setup mode, and emits a long stream of similar errors

    WARNING: the line:
    # whatever
    contains unsafe characters!

    Solution 1: Install pptp-php-gtk, and start it by typing pptpconfig. If you are not root, you will be prompted for the root password. You may find it much easier to configure than pptp-command.

    2003-05-02
     

    Solution 2: check for carriage return characters in the drop-in configuration file and remove them.

    % od -c /tmp/config|grep "\n"
    % tr --delete '\r' < /tmp/config > /tmp/config.new


  40. ERROR! Connection timed out

    Problem: pptp-command fails to start tunnel:

    ERROR! Connection timed out

    Diagnosis: older versions of pptp-command did not check effectively for success. They waited for the network interface to be created. If this did not happen within the time allowed, the error would appear.

    Solution: enable debug mode, start the tunnel manually, and look for the cause of the problem in the output. Check the rest of this document.

    Upgrade to the pptp-command shipped in 1.2.0 to be told when the tunnel fails rather than wait for the timeout.

    Consider an upgrade to pptp-php-gtk. Synchronisation of the user interface with PPP is more straightforward, and it is easier to use.

    2003-05-02
     


  41. New interface not found

    Problem: pptp-command fails to start tunnel:

    New interface not found.

    Diagnosis: pptp-command was told by pppd that the connection was established, but the network interface was no longer present. This is usually because pppd has failed after establishing the connection.

    Solution: enable debug mode, start the tunnel manually, and look for the cause of the problem in the output. Check the rest of this document.

    Upgrade to pptp-php-gtk, and start it by typing pptpconfig. Re-enter your tunnel data. When it fails to establish the tunnel, more information is provided.

    2003-05-02
     


Fault Tree


  1. Ping PPTP Server

    Prove that you can bounce ICMP echo request packets off the PPTP Server. If you can, this shows you have a network connection to it. If you can't, it doesn't prove anything, because it could be firewalled.

    # ping pptpserver


  2. Traceroute to PPTP Server

    Prove that you can trace the route to the PPTP Server. If you can, this shows you have a network connection to it. If you can't, again it doesn't prove anything, because it could be firewalled. However, only you can tell, given your knowledge of the network near you.

    # traceroute pptpserver


  3. Connect to port 1723 on PPTP Server

    Prove that you can connect to the PPTP Server on the TCP/IP port used for call management. If you can, this shows you have half the network connectivity you need. If you can't, you must fix the problem.

    # telnet pptpserver 1723


  4. Check GRE Works

    Prove that you can exchange GRE packets between the PPTP Server and the client. To do this, run a packet tracing tool such as tcpdump at the client while starting the tunnel. You should see a connection to port 1723, followed by GRE packets in both directions. If you are new to tcpdump, we have instructions.

    Gordon Chaffee and Neale Banks have contributed a patch to traceroute [link doesn't work, 2003-01] to provide an option to use GRE packets. This may prove useful to identify the cause of a GRE blockage.

    Common GRE blockages are as follows:


  5. Check MPPE Support

    MPPE support is required if you wish to connect to a PPTP Server such as Microsoft Windows VPN Server. MPPE is built as a Linux kernel module, and as a patch to the pppd program.

    Both of the following tests must pass for MPPE to function.


  6. Check MPPE in kernel Support

    Make sure the MPPE module can be loaded. If this module loads without error, then all is well with it. If errors are generated, you must find the cause and fix it.

    # modprobe ppp-compress-18

    There are numerous causes of a failure to load. Some of the causes are;


  7. Check MPPE in pppd Support

    Make sure the pppd program contains MPPE support by checking for option keywords in the file. If it contains MPPE options, then it has MPPE support. If it has no MPPE options, you must obtain or build an MPPE capable version.

    # strings `which pppd`|grep -i mppe|wc --lines

    For a pppd without MPPE support, the number displayed is zero. For a MPPE capable pppd, the number is about 38, but may vary.


Why are the pppd options different?

PPTP Client depends on PPP. See our diagrams for why. PPP needs MPPE support to interoperate with certain PPTP servers.

There are two PPP MPPE versions:

There are two parts to the PPP MPPE support, for each version. One part is in the kernel, and the other part is in the pppd program. These two parts must be the same general version. If they are mixed, the result can be that the pppd program reports the kernel has no support.

Comparing the two versions in detail:

PPP-MPPE 2.4.0

  • no further development?
  • no response to problems
  • has known problems such as kernel panics
  • OpenSSL license directly conflicts with kernel license
  • when loaded, does not indicate a license conflict
  • requires /etc/modules.conf changes
  • module file name mppe.o (or ppp_mppe.o)
  • +mppe-128 (inconsistent with existing option names)
  • mppe-stateless
  • require-chapms-v2 (incorrect protocol name)
PPP 2.4.2

  • ongoing development by PPP project
  • active response to problems by developers
  • has no known problems at this time (stay tuned)
  • BSD license does not conflict (as much) with kernel license
  • when loaded, indicates a license conflict
  • requires no /etc/modules.conf changes
  • module file name ppp_mppe.o
  • require-mppe-128
  • nomppe-stateful
  • require-mschap-v2
The two versions of pppd have different command line options.

If you are upgrading from the old PPP-MPPE 2.4.0 package, change /etc/ppp/options.pptp, and any existing tunnels in /etc/ppp/peers, to adopt correct naming for pppd options relating to MPPE support.

The following table compares the options between the versions.

PPP-MPPE 2.4.0 option PPP 2.4.2 option Explanation
mppe-40 require-mppe require-mppe requires the use of MPPE, disabling all other compression types, and enabling both 40-bit and 128-bit encryption. It is then up to the server what level of encryption is adopted. require-mppe-40 and require-mppe-128 are like require-mppe but use 40-bit and 128-bit encryption respectively, rather than allowing the server to choose.
mppe-128 require-mppe
mppe-stateless nomppe-stateful Stateless is now the default, you'd have to use mppe-stateful to turn it off.
require-chapms-v2 refuse-pap refuse-chap refuse-mschap refuse-eap A client cannot require a method of authentication of itself, but it can refuse a method offered. The "require" forms of these options are intended for use by servers, and if used on a client will force authentication of the server by the client, which will generally fail.

The option naming used previously on the PPTP Client project was for an unofficial MPPE patch to PPP. Since then, the PPP project has derived their own naming that is consistent with other pppd options.


What are those CCP MPPE bitmasks?

PPP negotiates MPPE with the PPTP Server using the Compression Control Protocol (CCP). When using debug logs, pppd decodes the CCP packets. How this is done depends on the version:

The following table describes the bits and their meanings:

PPP-MPPE 2.4.0PPP 2.4.2MeaningExplanation
0x01000000 +H Stateless use stateless encryption (less vulnerable to packet loss).
0x00000080 +M 56-bit use 56-bit key lengths for encryption (not supported).
0x00000040 +S 128-bit use 128-bit key lengths for encryption (less easy to decrypt than 40-bit).
0x00000020 +L 40-bit use 40-bit key lengths for encryption (more easy to decrypt than 128-bit).
0x00000010 +D Obsolete obsolete, usage unknown.
0x00000001 +C Compression use compression, see more about MPPC.

The values in the PPP-MPPE 2.4.0 column must be logically ORed. So, if you see a message <mppe 1 0 0 e1> this shows that the PPTP Server is prepared to support any of the above encryption types. Your system running pppd will likely respond with <mppe 1 0 0 60> which shows that it will not support MPPC, or 56-bit keys, but will support stateless 128-bit or 40-bit encryption.

Wanted: what the various PPTP Servers out there initially propose or will settle on given specific configuration options. We plan to build a list, to make it easier to understand why certain PPTP Servers are giving trouble.


How to use tcpdump?

tcpdump can be used to capture the packets exchanged between the PPTP Client and the PPTP Server. By comparing the packets with what should be happening, you can determine what the cause of a problem might be. Give to tcpdump the name of the network interface that connects to the PPTP Server, which for dial-up users would be ppp0, and for ADSL users eth0. Then, in another window or console, start the tunnel.

# tcpdump -i ppp0
# pppd call tunnel

You should see a connection to port 1723, followed by GRE packets in both directions. If you can see this, then you have full network connectivity. If you can't, you must find the problem.

If you get:

tcpdump: pcap_loop: read: Network is down

then you may be using tcpdump on the wrong interface. Use ifconfig to list the available interfaces and choose the one through which your client must contact the server. See our diagrams if you're still confused.


How to enable debug logging?

Add the options debug dump to the pppd command line or options file, then retry the connection. Further information is below. Enabling debug logging is necessary to determine the cause of certain problems. It also gives more information as to why an event happened.

Security Warning
Usernames and passwords from your chap-secrets file may be included in the debug log if you are using the old ppp-mppe package. If you do not want to give away this information, remove it before sending the log to someone else.

How you enable debug logging depends on the method you use to start the tunnel.

usual commandenabling debug logging
pptp-php-gtk click on the tunnel, click on Miscellaneous, click on Enable connection debugging facilities, click on Update, click on Start, examine the output.

Or, if the problem is occuring after a successful connection report:

pppd call tunnel logfd 2 nodetach debug dump

where tunnel is the name of the tunnel you created using the GUI. This command is similar to what the GUI uses to start the tunnel, except for the change to the logfd and nodetach.

pptpconfig
pptp-command start start the tunnel manually by typing:

pppd pty 'pptp server --nolaunchpppd' call tunnel debug dump logfd 2 nodetach

Where server is the IP address or host name of the PPTP Server, and tunnel is the name of the /etc/ppp/peers entry that pptp-command created for you.

pon tunnel add
debug dump logfd 2 nodetach

to the end of the command

pptp ip call tunnel
pppd pty 'pptp ip --nolaunchpppd' call tunnel

The dump phrase includes in the debug log each option given to pppd. This is very useful for others who are trying to help you with a problem.

2003-05-14
 

The logfd 2 nodetach phrase is necessary to prevent debug messages from being sent to the PPTP Server, which may confuse it.

To ease collection of the debug log, use the script command to record the output. For example:

# script test.log
# pon tunnel debug dump logfd 2 nodetach

After the command exits, type Control/D or exit and the test.log file will contain a complete log of the session since the script command.


Known Working Log

The following log shows what might normally be expected to appear for a successful connection from a Debian GNU/Linux (potato) client to a Microsoft Windows NT VPN Server. Use this for comparison against your log. The debug option has been supplied to pppd.

# pon tunnel
Using interface ppp1
Connect: ppp1 <--> /dev/pts/1
Looking for secret in /etc/ppp/chap-secrets for client domain\username server PPTP
Got client domain\username
Got server PPTP
Got secret PPTP
Got client password
sent [LCP ConfReq id=0x1 <mru 1000> <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
rcvd [LCP ConfReq id=0x0 <auth chap 81> <magic 0x6fe7> <pcomp> <accomp>]
sent [LCP ConfAck id=0x0 <auth chap 81> <magic 0x6fe7> <pcomp> <accomp>]
rcvd [LCP ConfNak id=0x1 <mru 1500>]
sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
rcvd [LCP ConfAck id=0x2 <asyncmap 0x0> <magic 0x5d4790f> <pcomp> <accomp>]
sent [LCP EchoReq id=0x0 magic=0x5d4790f]
rcvd [CHAP Challenge id=0xf4 <13b0a50a64cb40e5e2afbb47186f8255>, name = ""]
Looking for secret in /etc/ppp/chap-secrets for client domain\username server PPTP
Got client domain\username
Got server PPTP
Got secret PPTP
Got client password
sent [CHAP Response id=0xf4 <b6 ... 00>, name = "domain\\username"]
rcvd [LCP EchoRep id=0x0 magic=0x6fe7]
sent [CHAP Response id=0xf4 <b6 ... 00>, name = "domain\\username"]
rcvd [CHAP Success id=0xf4 "S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67"]
Remote message: S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67
sent [IPCP ConfReq id=0x1 <addr 10.0.0.1> <compress VJ 0f 01>]
sent [CCP ConfReq id=0x1 <mppe 1 0 0 60>]
rcvd [CCP ConfReq id=0x1 <mppe 1 0 0 61>]
sent [CCP ConfNak id=0x1 <mppe 1 0 0 60>]
rcvd [IPCP ConfReq id=0x2 <addr 168.192.232.31>]
sent [IPCP ConfAck id=0x2 <addr 168.192.232.31>]
rcvd [CHAP Success id=0xf4 "S=B8C96D7EC7960C2EC2C096D5C5256C711D435C67"]
rcvd [IPCP ConfRej id=0x1 <compress VJ 0f 01>]
sent [IPCP ConfReq id=0x2 <addr 10.0.0.1>]
rcvd [CCP ConfNak id=0x1 <mppe 1 0 0 40>]
sent [CCP ConfReq id=0x2 <mppe 1 0 0 40>]
rcvd [CCP ConfReq id=0x3 <mppe 1 0 0 40>]
sent [CCP ConfAck id=0x3 <mppe 1 0 0 40>]
rcvd [IPCP ConfNak id=0x2 <addr 168.192.232.42>]
sent [IPCP ConfReq id=0x3 <addr 168.192.232.42>]
rcvd [CCP ConfAck id=0x2 <mppe 1 0 0 40>]
MPPE 128 bit, stateless compression enabled
rcvd [IPCP ConfAck id=0x3 <addr 168.192.232.42>]
Cannot determine ethernet address for proxy ARP
local IP address 168.192.232.42
remote IP address 168.192.232.31
Script /etc/ppp/ip-up started (pid 14084)
Script /etc/ppp/ip-up finished (pid 14084), dUmMy= 0x0


Comments

If you have comments on this document, please send them to the author at james.cameron at hp.com.

ChangeLog

DateChange
2003-06-05
Add "MPPE required, but kernel has no support." Reordered the PPP comparison section. Added automatic dates to the end of each change-bar section.

 

2003-05-30
Add "LCP ConfRej <auth chap MS-v2>" for new PPP version, and remove text that used to say MPPE was required for MS-CHAP-V2 to work. Thanks to Gail Songer.

 

2003-05-29
Add "EAP Response" thanks to Doug Langille.

 

2003-05-26
Add "CCP terminated by peer".

 

2003-05-14
Suggest dump in addition to debug.

 

2003-05-02
Changed MPPE module test to use ppp-compress-18. Total review of document, added additional solutions in light of recent release of pptp-linux 1.2.0, the pptp-php-gtk GUI, and the kernelmod instructions.

 

2003-04-14 Add nopcomp as a solution to unsupported protocol 0x2145 received. Suggested by Peter Wilsmore, with confirmation from Bart Coninckx, Duncan Gibb and Abel Lucano.

2003-04-08 Clarify require-mppe option naming. Suggested by Chris King.

2003-04-01 Add another two paths to the IP loop section. Contributed by Frederick C. Druseikis and Sascha Scholz.

2003-03-24 Changes for PPP 2.4.2. Change MPPE option names. Add section explaining option differences. Change MPPE bitmasks section.

2003-03-21 Add special comments for enabling debug logging with pptp-php-gtk when the problem occurs after successful connection.

2003-03-20 Add a new error message reported by pptp-command.

2003-03-17 Add another reason for GRE loss, thanks to Manuel Clos.

2003-02-06 Add pptp-command timeout error, and simplify debug logging section.

2002-12-30 Add contributed (and far simpler) solution to the same-ip problem from Markus Gaugusch.

2002-12-24 Fix incorrect 57-bit reference.

2002-12-23 Include reference to MPPC work by Jan Dubiec.

2002-12-20 Mentioned passwords that contain hash characters, thanks to Chad Beattie.

2002-11-21 Described why ip_gre module acts as a workaround for the protocol not available error.

2002-11-13 Added Eric Stanley's iptables and ip solution to the same IP address dilemma. We met on the #pptp IRC channel, he had the same problem others had, but had the knowledge and experience required to fix it.

2002-11-11 Asked for more information on insecure dependency errors.

2002-10-31 Added another cause for "remote system is required to authenticate". Added routing problems. Added the old insecure dependency error.

2002-10-25 Added another cause for LCP timeout; client transmits sync packets but the server returns asynchronous. Thanks to Ernst via the support tracker.

2002-09-10 Greeno on irc.openprojects.net found that the write to a GRE socket could fail with Operation not permitted if iptables rules were set to prevent GRE traffic.

2002-08-20 Added pointer to ppp_generic.c patches in CVS, and comment about SuSE 8 kernel not including them. Thanks to Carsten Grammes.

2002-08-07 Barvaz encountered a ClarkConnect firewall rule set that stopped all GRE traffic; another cause for no GRE packets being transmitted. Ravi found that the EPROTO error can be fixed by binding the GRE socket early. James documented the use of --clamp-mss-to-pmtu for connections that freeze.
2002-07-17 Mike Machado found a solution for the "short read Protocol not available" problem. Added a CHAP authentication failure due to excessive slashes between domain and username. Noted that the module name may be either ppp_mppe or mppe, thanks to Joona Palaste and Mike Machado.
2002-06-11 Frank Kelbe found a new cause for the authentication required problem, which was caused by overwriting modules after initial installation of MPPE capability.
2002-05-29 Add short read caused by noauth missing. Add remote system required to authenticate. Add explanation of CCP MPPE bitmasks and link log references to the section. Note results of Frank's investigation into FreeBSD MPPC support. Improve conflicts with kernel solution.
2002-05-15 Further clarify the possible causes for MPPE failures, fix links to Fault Tree section, and add a section on 'command not found'. Remove a few HTML structure faults found using weblint. Break out from the page content table to better use the screen space.
2002-05-10Add protocol reject due to mppe-40 being forced on at the PPTP Server.
2002-05-07Add network is unreachable, remove mail addresses.
2002-05-02Fix ambiguity on which interface to use when using tcpdump.
2002-05-01Add note about char-major-108. Clarify logging to stderr.
2002-04-30Add Huelbe Arizon Garcia's IP loop problem as discussed on pptpclient-devel mailing list. Add Mary Deck, James Kenworthy and Farrell Woods problem with carriage returns in pptp-command drop-in configuration files as discussed on an internal Compaq mailing list. Moved to site links.
2002-04-15Add Jes Sorensen's problem when pppd is set to use sync option. Rework section titles and introduction. Add table of contents, conventions and ChangeLog.

privacy and legal statement