|
|
|
|---|
| |||
| |||
| |||
| |||
| |||
|
| 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 |
| Fatal error: php-gtk: Could not open display in /usr/bin/pptpconfig.php on line 31 |
which may be preceeded by
| Xlib: connection to ":0.0" refused by server Xlib: Invalid MIT-MAGIC-COOKIE-1 key |
| Diagnosis: you have used su to become root but
that is insufficient to pass on the access to the graphics display.
This is a security feature of X-Windows. Solution: see the command not found entry below, as it covers the same problem but from a different error message.
2006-08-21 | |
Problem: pptp-command fails with a message about an insecure dependency and the -T switch.
|
Solution 1:
Install pptpconfig, 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.
| WARNING: the line: # whatever contains unsafe characters! |
|
Solution 1:
Install pptpconfig, 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 |
| 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 pptpconfig. Synchronisation of the user
interface with PPP is more straightforward, and it is easier to
use.
2003-05-02 | |
| 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 pptpconfig, 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 | |
| Symptom: when trying to start pptp, pptpconfig,
or pptpsetup as a non-root user, this message appears:
Diagnosis: the program is not in your PATH, or you are not running the program as the root user. This is a normal security feature of most systems. The solutions depend on which program you are running. pptpconfig The pptpconfig program needs access to your X-Windows display, write access to /etc/ppp/peers, /etc/pptpconfig, and also needs to start pppd and pptp which themselves need root. Choose one of these methods:
The pptpsetup program needs write access to /etc/ppp/peers, /etc/pptpconfig, and also needs to start pppd and pptp. Choose one of these methods:
pptp requires root privilege to create a raw socket for GRE packet transmission. pptp is in /usr/sbin, which is in the PATH for the root user. pptp is started by pppd. Follow this sequence:
2006-08-21 | |
| 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.
| 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.
| 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.
| 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.
|
Symptom: on a PPTP server running pptpd, the following
message may appear when all incoming tunnel requests fail:
Diagnosis: pppd was started by pptpd but was unable to operate, and so terminated quickly. pptpd 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. pptpd incorrectly hides all pppd error output. This is a defect and should be fixed. It apparently doesn't even wait for and report the pppd exit status. Solution: check the configuration files. A simple typo will cause this error. It is easy to have pppd tell you where the typo is. Here is how: Try running pppd against the configuration files in the same way that pptpd would run it. If you strace the pptpd, you can detect the command line given to pppd (just after it says "launching pppd"), and then you can run that command manually in a shell to see what objections pppd has to the options. When we did an strace just now, we got this line that was valuable;
This tells us that pptpd is trying to execute the following command to accept the tunnel connection from the client (we have speed 50 in our options file);
Running this command in a shell starts pppd negotiating with the keyboard and screen. After a while it times out. Adding the dryrun option allow us to test the syntax only. We added the word bogus to our pptpd-options file (your file name may differ), and the result was as follows:
pppd had returned an exit status of 2, which according to the manual page means "An error was detected in processing the options given, such as two mutually exclusive options being used." Removing the word bogus caused pppd to exit with a status of 0. We used the shell command echo $? to check the exit status. As to why the error messages from pppd are being ignored, the running pppd on our test server has file descriptor 2 (stderr) bound to a deleted pty. We presume this is a code fault in pptpd.
2003-09-02 | |
| 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 | |
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.
|
Symptom: while running pptp, this message appears, which
may or may not be associated with any other problem:
Diagnosis: this is a normal situation. Many network links drop or re-order packets as a normal part of their operation. This message informs you that a packet was lost or re-ordered. The TCP network infrastructure above this level will retransmit the lost data. (out-of-order in this context relates to the sequence of the packets, and should not be confused with the use of the phrase in some locales to warn that public equipment is not operating.) Solution: if the loss is higher than the physical layer should provide, check the physical layer for problems. You can also use the link statistics feature of pptp, see the man page for how to obtain and understand the statistics.
2004-02-16 | |
| 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.
|
Symptom: the following messages appear before connection is
established:
Diagnosis: pppd has failed to change the pty over to run it in PPP mode. This may be because you have no ppp_async module built for your kernel. Most kernels are built with this already, but if you have customised your kernel you may not have built it. Solution: rebuild your kernel with CONFIG_PPP_ASYNC set. While you are at it, you should set CONFIG_PPP as well, and both should be set to "m" so that they are built as modules. We've found they don't work compiled statically.
2004-02-02 | |
| 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.
| 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 required to authenticate 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.
Other causes are:
2003-12-15 | |
| Often the E=nnn error number above is followed by a R=0
or R=1, which means the server is disallowing or
allowing a retry respectively. pppd on Linux generally
doesn't use the opportunity to retry. There may also be an
opportunity to change the password, but this is not well understood
here.
2006-01-24 | |
| Problem:
pppd displays an error:
Diagnosis: error code 649 is ERROR_NO_DIALIN_PERMISSION, the account does not have dialin permission. Solution: ask the server administrator to give your account dialin permission.
2003-12-15 | |
| 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.
| 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 noauth option is in the options file, or given to pppd via the command line. Make sure that require-mschap-v2 require-mschap require-chap require-pap require-eap options are not used.
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.
| Problem: connection fails and the logs contain this message:
Diagnosis: pppd has completed IPCP negotiation with the peer (e.g. the PPTP server) and was about to raise the new network interface, but found that neither the peer, the command line, or the hostname gave a valid IP address. Usually, the peer provides the IP address during IPCP negotiation. You can examine the debug log to determine how this negotiation proceeded. Solution: choose one:
pppd tries to determine your local IP address using the host name. On systems installed without a hostname, this may fail. So set a hostname using the hostname command, and add the IP address to /etc/hosts. This change may require the restart of other processes.
2004-03-08 | |
There are many causes for the timeout error:
Use tcpdump to check the flow of GRE packets.
Diagnosis: PPTP servers will not allow a connection to start from the same IP address that they perceive an active connection on already.
Solution: use alternate PPTP server IP addresses.
| rcvd [proto=0x7eff] 7d 23 c0 21 7d 21 7d 21 7d 20 7d 39
7d 22 ...] |
Diagnosis: you may be running pppd with the sync option, with a version of the GRE-to-PPP gateway that will recognise sync mode, but the server is returning asynchronous responses.
Solution: turn off sync and try again.
Symptom: tcpdump shows no GRE packets are being transmitted by the client. strace shows no write() on the GRE socket by the GRE-to-PPP gateway process.
Diagnosis: you may be running pppd with the sync option, which prevents older version of the GRE-to-PPP gateway from forwarding the packets.
Solution: turn off sync and try again.
Symptom: tcpdump shows no GRE packets are being transmitted by the client. However, strace shows a successful write() on the GRE socket by the GRE-to-PPP gateway process.
Diagnosis: your system may have iptables or ipchains rules that prevent GRE transmission. The GRE-to-PPP gateway sends the packets, but they are dropped by the packet filter before being transferred to the interface.
Solution: check the firewall rules, remove or add replacements, and try again. The following iptables rules may be added to allow GRE through eth0. Change eth0 to the name of the interface through which the PPTP Server is contacted.
| iptables --insert OUTPUT 1 \ --source 0.0.0.0/0.0.0.0 \ --destination 0.0.0.0/0.0.0.0 \ --jump ACCEPT --protocol gre \ --out-interface eth0 iptables --insert INPUT 1 \ --source 0.0.0.0/0.0.0.0 \ --destination 0.0.0.0/0.0.0.0 \ --jump ACCEPT --protocol gre \ --in-interface eth0 |
These rules can be refined further to constrain the GRE traffic.
Diagnosis: you may be running pppd with the pty option and the debug option but not the logfd 2 option. This can cause pppd to send the debug messages out the psuedo-tty file descriptor to the GRE-to-PPP gateway process, and then to the PPTP Server. The server refuses to respond once it sees random traffic like this.
Solution: Add the logfd 2 option.
| rcvd [LCP ConfReq id=0x0 <auth chap 81> <magic 0x7a73> <pcomp> <accomp>] sent [LCP ConfRej id=0x0 <auth chap 81> |
See next item below.
|
Symptom: you are using PPP 2.4.2 or later and logs contain this
sequence:
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:
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:
Any spaces or special characters in the local name, password, or remote name must be properly quoted. The hash character (#) in a password is a definite cause of this; add quotes around the password to fix it. See man pppd section AUTHENTICATION for more details. Solution: fix the chap-secrets file or the pppd options so that they match.
2005-06-02 | |
See below for the most likely cause.
| 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. 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.
See the next two sections below for the most likely causes.
|
Symptom: an LCP TermReq occurs immediately after an EAP
Response, as per this example log:
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 | |
|
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 | |
| 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.
| 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.
| Symptom: logs contain this message:
Diagnosis: you have given pppd the option require-mppe which forces the use of encryption, but the authentication phase did not use MS-CHAP[v2], it used something else. MPPE requires the use of MS-CHAP[v2] for establishing initial encryption keys. pppd terminates once it detects this conflict. Solution: either fix the authentication or remove require-mppe. To find out how authentication happens, enable debug logging, try the connection again to determine what method the peer is offering for authentication. Then configure pppd to refuse that method. Or, add the following pppd options:
These options configure pppd to refuse to authenticate using certain protocols. As a result, the peer will attempt other protocols, hopefully MS-CHAP[v2]. Do not use require-mschap-v2 because this asks pppd to authenticate the peer, a reversal of what is normally done.
2006-03-27 | |
|
Symptom 1: logs contain this sequence:
or Symptom 2: debug logs contain this sequence:
Diagnosis: the local pppd is refusing to accept the level of MPPE encryption required by the peer. The peer insists on that level, and so it terminates the connection. In the case above, the local pppd has proposed no encryption or compression, but the peer has requested stateless 128-bit encryption. The local pppd rejects the proposal from the peer. Solution: if you are using the GUI, select the tunnel, click on on the Encryption tab, turn on Require Microsoft Point-to-Point Encryption (MPPE), and Update, and try to Start the tunnel again.
Otherwise, make sure the require-mppe option is provided to the pppd command, such as in the options file or the command line.
2003-06-17 | |
| Symptom: require-mppe-128 option is set, and debug logs contain this sequence:
with the essential component being the immediate termination by the local host on receipt of a CCP ConfReq that has the encryption bits turned off (-M -S -L). Diagnosis: this is a defect of pppd on your system. It is terminating the connection on the basis that the peer started to suggest no encryption. Your pppd is not first negotiating to achieve encryption. The version of pppd you are using takes the require-mppe-128 option pedantically; refusing to connect if the peer is configured to allow no encryption, even if the peer may allow encryption after negotiation.
2005-01-19 | |
Solution: you may fix this by (either);
2006-03-09 | |
If the peer is a server is on the public internet, you may wish to warn the administrator that it is not set to require encryption, and so tunnels may be established in the clear, which is an information security risk. If they change the configuration to require encryption, this seems to fix this problem, because the initial negotiation attempt includes MPPE.
2005-01-19 | |
|
(If the peer is Microsoft Windows 2000 acting as a server, check that
the No Encryption option in Remote Access Policies is
disabled. Rob Gamble provided us with instructions to fix
this.)
2003-08-12 | |
|
Symptom: debug logs contain this sequence:
Diagnosis: You have directed the local pppd to require MPPE, but the negotiation with the peer failed to find a compatible encryption level and method. In the case above, the local pppd has proposed stateless 128-bit encryption and compression, but the peer has requested stateless 40-bit encryption and no compression. The local pppd was built without 40-bit MPPE support, or 40-bit MPPE was disabled, and so it decided it could not proceed. Depending on the debug messages that appear prior to the "MPPE required but peer negotiation failed" message, there may be other causes. Please write to the mailing list if you've found one that we haven't documented, and include the debug messages. Solution: Rebuild pppd for 40-bit MPPE support, enable 40-bit MPPE support, or change the peer to accept 128-bit MPPE. (If the peer is Microsoft Windows XP acting as a client, change properties for the VPN connection, select the security tab, then the settings button next to advanced. Under Data encryption, select "Maximum strength encryption". Contributed by Bob Elzer.)
2003-06-16 | |
|
(If the peer is Microsoft Windows 2000 acting as a server, try adding the pppd options nomppe-stateful, nobsdcomp and novj.
Contributed by Andrew Cilia.)
2003-10-13 | |
|
Symptom: debug logs contain this sequence:
See below.
2003-06-05 | |
|
Symptom: logs contain this sequence:
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. For a bit more history on this, 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:
Identifying the version of PPP's MPPE kernel module is not as straightforward. It is best to know where it came from originally. Linux kernel 2.6.15 or later include the module already. If you've used a patch, use the command:
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 or later 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 | |
|
Problem: the error message "Received bad configure-ack" appears
as a result of starting a connection. Diagnosis: PPP has received a configuration acknowledgement from the peer that differs substantially from a request it made. This indicates a faulty peer implementation. 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. See below for one known cause.
2003-07-09 | |
|
Problem: the peer persists in refusing an MRU value other than
1500, eventually sending a bad configure ack, as per the following
log:
Diagnosis: this happens with certain peers if the mru option is used to attempt to restrict the maximum receive unit (MRU) size. Solution: remove the mru option. MRU is separate to MTU, and MTU restriction for ICMP blocked PPTP servers is usually sufficient.
2003-07-09 | |
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:
| 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. |
| Symptom: on kernel 2.6.15 or later, Gentoo pppd created with
USE mppe-mppc emerge flags, connection is established, but after MPPE
is negotiated no data transfer happens, and the pppd log shows
"Protocol-Reject for unsupported protocol". Diagnosis: the MPPC patch to pppd is not compatible with kernel 2.6.15 MPPE kernel module. Solution: either downgrade to the previous kernel or re-emerge ppp without the mppe-mppc flags.
2006-01-23 | |
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 1: add nomppe-128 to the options given to pppd.
| Solution 2: if using PPP-MPPE 2.4.1 on Mandrake, ensure
mppe-stateless is included in the options given to pppd.
2003-10-14 | |
| 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.
| 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. We list some possible reasons and actions that can be taken:
2004-04-06 | |
| 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]
Problem: TCP connections via the tunnel freeze once they attempt to transfer large amounts of data.
|
Diagnosis: path MTU discovery may be failing due to ICMP
blocking by hosts after the PPTP server. Solution: manually restrict the MTU on the interface, by adding mtu 1404 or some smaller value as an option to the pppd program, either in the peers file for the tunnel, in the options file, or on the command line. You can also restrict the MTU on the interface after the tunnel has connected, using a command like ifconfig ppp1 mtu 1400. The effect is that new TCP connections from your host will use an maximum segment size (MSS) that is lower. This may prevent path MTU discovery from being necessary.
2004-02-09 | |
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 fragmentation needed responses.
Solution: if using Linux 2.2, reduce the MTU on all hosts using the PPTP Client host as their route, e.g. ifconfig eth0 mtu 1400. If using Linux 2.4 or later, 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.
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.
Diagnosis: this is a reported problem in PPP 2.4.2 with a known cause.
Solution: either undo the change in the source or downgrade to a CVS snapshot of PPP dated 20040102.
|
Problem: when attempting to manually install the MPPE module,
using modprobe ppp_mppe (instead of modprobe
ppp-compress-18 as we suggest), the following error is
displayed:
Diagnosis: you may have an old alias ppp-compress-18 mppe line in your /etc/modules file from a previous installation, and the mppe.o module may already be loaded. Solution: remove the line, it is no longer needed with PPP versions 2.4.2 or later. Reboot, and try again. If rebooting is costly, ensure the module is removed, and try depmod -a.
2003-10-24 | |
| Problem: a client on Microsoft Windows 98 calling a PPTP server
displays an error:
Diagnosis: a connection was made to port 1723 on the server, but the server did not accept or send any data, and the connection was closed. Use tcpdump or ethereal on the server side to analyse the packet stream with the client, and determine what to do. A common cause is an /etc/hosts.allow file that prevents the connections from continuing. pptpd uses the hosts_access(3) access control library in a similar manner to the inetd filter program tcpd. An strace of pptpd shows that it opens hosts.deny and hosts.allow for each connection. A test for whether this is the cause can be done from the client, using a telnet or general purpose TCP/IP connection program. Connect to port 1723 on the PPTP server (telnet 10.0.0.150 1723), but send no data. Normally the connection is accepted and the server waits for data to be sent. If the connection is accepted and then immediately closed, then the cause is likely to be host access control. Solution: if the cause of the disconnection is the hosts.allow file, add the following line to it:
Or to marginally increase the security of your tunnel server, identify the subnets that should have access and add them to the list. The following example allows access from any host with an IP address in the range 10.x.x.x:
For more information see:
[links not recently verified]
2003-09-04 | |
| # ping pptpserver |
| # traceroute pptpserver |
| # telnet pptpserver 1723 |
| For diagnosing the point at which GRE is lost in a network path;
Note: these days with the profusion of cheap consumer-grade NAT routers and gateways, hping2 and GRE traceroute do not work as well as one would like. This is because most NAT routers use stateful inspection of the PPTP control connection to determine how and when to forward the GRE packets. Concentrate on block-box analysis using tcpdump at the end points you have access to.
2006-04-12 | |
Common GRE blockages are as follows:
Hosts between your client and the server through which GRE must pass may be configured to block GRE. Using the GRE traceroute programs above you may be able to identify the host that is causing the block.
The client may be configured to block GRE packets as they arrive, or before they depart. Check your iptables or ipchains configuration.
If you have a NAT gateway, such as a DSL router, that presents one IP address to the network on which the PPTP Server is contacted, then only one PPTP connection can be active at once. The PPTP Server will only accept one.
Attempting to start a second tunnel to another IP address may also fail if the NAT software cannot differentiate the two connections. This may cause the first connection to fail.
If the PPTP Server fails to start pppd because of a syntax error in the options file or command line, the effect mimics a total loss of GRE packets from the server end. Check the server logs carefully. Start pppd manually at the server to test the options.
Both of the following tests must pass for MPPE support to function.
| # modprobe ppp-compress-18 |
If this module loads without error, then all is well with it. If errors are generated, you must find the cause and fix it. There are numerous causes of a failure to load. Some of the causes are;
2003-08-01 | |
| # strings `which pppd`|grep -i mppe|wc --lines |
For a pppd without MPPE support, the number displayed is zero. For an MPPE capable pppd, the number is about 38, but may vary.
There are three PPP MPPE versions, and their history is shown in the graph below:
Comparing the two versions in detail:
|
PPP-MPPE 2.4.0
|
PPP 2.4.2 and later
|
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.
| PPP-MPPE 2.4.0 | PPP 2.4.2 | Meaning | Explanation |
|---|---|---|---|
| 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.
|
