pptp问题调试详解

最新推荐文章于 2024-06-03 09:57:27 发布
最新推荐文章于 2024-06-03 09:57:27 发布
阅读量2.6w 收藏 8
点赞数
分类专栏： pptp与GRE

Diagnosis HOWTO

by James Cameron
12th April 2006

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 a series of known problems in installation and running 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.

Near the end of the document, we also show a fault tree, and some additional documentation for using tools to determine what your problem is.

We thank the many contributors to this page. If you think you've found a solution to a common problem, please write it up in our problem,diagnosis, solution format, and submit it to the mailing list.

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)

Installing kernel modules

    Installing pppd

    • 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

    Installing pptp

      Installing pptpconfig

        Running pptpconfig

        • Fatal error: php-gtk: Could not open display
          Symptom: trying to start pptpconfig results in an error;

          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

        Running pptp-command

        • 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 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: 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 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
          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 pptpconfig. Synchronisation of the user interface with PPP is more straightforward, and it is easier to use.

          2003-05-02

        • 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 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

        Running pptp

        • pptp: command not found
          Symptom: when trying to start pptp, pptpconfig, or pptpsetup as a non-root user, this message appears:

          pptp: command not found

          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:

          1. configure sudo to allow a user to run pptpconfig as root without any password prompt, for example:

            # echo ALL ALL=NOPASSWD: /usr/sbin/pptpconfig >> /etc/sudoers

            add a desktop launcher item which runs this:

            % sudo /usr/sbin/pptpconfig

            and since pptpconfig presumes both pptp and ip are in the PATH, either create symlinks:

            % ln -s /usr/sbin/pptp /usr/bin/pptp
            % ln -s /sbin/ip /bin/ip

            or augment PATH in the usual fashion.

          2. use kdesu if it is installed; type kdesu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.

          3. use gksu if it is installed; type gksu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.

          4. use gnomesu if it is installed; type gnomesu pptpconfig and press enter. You may be prompted for the root password, and then the pptpconfig window should appear.

          5. use ssh to forward the X11 connection; type ssh -X root@localhost pptpconfig and press enter. You may be prompted for the root password. The sshmethod may not work if your /etc/ssh/sshd_config file has X11Forwarding set to no. Another security feature.

          6. log in as root to begin with. On some distributions, you can configure the connection using pptpconfig as root, and then start the tunnel using pon tunnelname as an ordinary user.

          7. adjust the definition of the menu option for pptpconfig by adding whichever wrapper above worked for you.

          pptpsetup

          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:

          1. configure sudo to allow you to start pptpsetup, as described in the section above,

          2. use ssh; type ssh root@localhost pptpsetup and press enter. You may be prompted for the root password.

          3. log in as root to begin with. On some distributions, you can configure the connection using pptpsetup as root, and then start the tunnel using pon tunnelname as an ordinary user.

          4. configure pptpsetup to be setuid root:

            # chmod u+s `which pptpsetup`

          pptp

          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 bypppd. Follow this sequence:

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

          2. as root, configure the tunnel with pptpconfig or pptpsetup, and test it, but then stop using pptpconfig or pptpsetup as the way to start it,

          3. make pptp setuid root:

            # chmod u+s `which pptp`

          4. test that a pppd command 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.

          5. 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

          6. you may need to add a host route to the PPTP server first, which is something that pptpconfig does for PPTP Client 1.7.1 and earlier,

          7. if you used any special routing in pptpconfig then you will need to duplicate this at the command line. Enable debug logging in pptpconfig to see exactly what commands it is executing and when.

          2006-08-21

        • 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.

        • 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.

        • 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.

        • 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.

          Symptom: on a PPTP server running pptpd, the following message may appear when all incoming tunnel requests fail:

          pptpd[5740]: GRE: read(fd=5,buffer=804dc00,len=8196) from PTY failed: status = -1 error = Input/output error

          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 topppd (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;

          12704 execve("/usr/sbin/pppd", ["/usr/sbin/pppd", "local", "file", "/etc/ppp/pptpd-options", "50", "10.0.1.1:10.0.1.3"], [/* 18 vars */]) = 0

          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);

          pppd local file /etc/ppp/pptpd-options 50 10.0.1.1:10.0.1.3

          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 local file /etc/ppp/pptpd-options 50 10.0.1.1:10.0.1.3 dryrun
          pppd: In file /etc/ppp/pptpd-options: unrecognized option 'bogus'

          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

        • 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

        • 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.

        • buffering out-of-order packet
          Symptom: while running pptp, this message appears, which may or may not be associated with any other problem:

          log[decaps_gre:pptp_gre.c:397]: buffering out-of-order packet 272 (expecting 271)

          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

        Running pppd (before connection)

        • 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.

        • Couldn't set tty to PPP discipline: Invalid argument
          Symptom: the following messages appear before connection is established:

          Serial connection established.
          Couldn't set tty to PPP discipline: Invalid argument
          Hangup (SIGHUP)

          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
          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. Enablingdebug 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 bypptp.

        • 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 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.

        Running pppd (during connection)

        • 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.
          Other causes are:
          1. invalid format for domain and username,
          2. specifying the wrong domain (E=691),
          3. restrictions on logon hours (E=646),
          4. account is disabled (E=647),
          5. account password expired (E=648),
          6. not having dialin permission (E=649),
          7. specifying the wrong password (E=691), (e.g. by not quoting special characters),
          8. using spaces or blanks as part of your password (E=691), (our tests show this doesn't work).

          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

        • No dialin permission
        • Unknown MS-CHAP authentication failure: E=649
        • Remote message: Unknown authentication failure: E=649
          Problem: pppd displays an error:

          Remote message: Unknown authentication failure: E=649 R=0
          CHAP authentication failed

          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

        • 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.

        • 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 noauth option is in the options file, or given to pppdvia 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 themisc/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.

        • Could not determine local IP address
          Problem: connection fails and the logs contain this message:

          Could not determine local IP address
          sent [IPCP TermReq id=0x4 "Could not determine local IP address"]

          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:

          1. provide an IP address on the command line, (see man pppd in the section marked OPTIONS, or just add the IP address followed by a colon, e.g. 10.0.0.1:),
          2. change the peer configuration to suggest a local IP address,
          3. ensure that the noipdefault option is not being used, and that the system hostname translates to an IP address.

          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 thehostname command, and add the IP address to /etc/hosts. This change may require the restart of other processes.

          2004-03-08

        • LCP: No network protocols running
          See below.

        • 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 peer, 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
          • If you see a series of  sent [LCP ConfReq ...] messages with no  rcvd messages, then you may not have GRE connectivity to the PPTP Server. Prove this using the  GRE step in the  Fault Tree.

          No GRE transmitted by PPTP Server
          • Symptom: GRE packets are emitted by the client, but none are returned by the server, but a tunnel from another machine on the same LAN works fine. The client is behind a NAT gateway with respect to the server.

            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.

          Invalid GRE packets transmitted by server
          • Symptom: GRE packets are emitted by the client, GRE packets are returned by the server, but the client makes no sense of them, reporting in the debug log the following asynchronous PPP packet:

            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.

          No GRE packets transmitted by client
          • There are two known causes.

            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.

          Invalid GRE packets transmitted by client
          • Symptom: 10 or more GRE packets are emitted by the client in less than a second, and the number of GRE packets is far greater than the number of LCP requests logged.

            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.

        • 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.

        • LCP ConfRej <auth chap MS-v2>
        • No auth is possible
          Symptom: you are using PPP 2.4.2 or later and logs contain this sequence:

          rcvd [LCP ConfReq id=0x0 <auth chap MS-v2> <magic 0x7a73> <pcomp> <accomp>]
          No auth is possible
          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, (see below for causes)
          • pppd was built without MS-CHAP-V2 support (quite 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. Theremotename 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. 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

        • 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.

        • 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. 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.

        • 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.

        • 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.

        • 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^@<m-mt^@^@^bm- )="" <="" small="">

          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 pppdoptions.

          2003-05-26

        • 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

        • 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 themisc/mppe.o and kernel/drivers/net/ppp_generic.o modules.

          Solution 2: reinstall the two modules.

        • CCP: No compression negotiated
          See below.

        • 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.

        • MPPE required, but MS-CHAP[v2] auth not performed.
          Symptom: logs contain this message:

          MPPE required, but MS-CHAP[v2] auth not performed.

          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:

          • refuse-eap
          • refuse-pap
          • refuse-chap
          • refuse-mschap

          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

        • MPPE required but peer refused
          Symptom 1: logs contain this sequence:

          LCP terminated by peer (MPPE required but peer refused)

          or

          Symptom 2: debug logs contain this sequence:

          sent [CCP ConfReq id=0x1]
          rcvd [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
          rcvd [CCP ConfAck id=0x1]
          sent [CCP ConfRej id=0x1 <mppe +H -M +S -L -D -C>]
          rcvd [LCP TermReq id=0x2 "MPPE required but peer refused"]

          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

        • MPPE required but peer negotiation failed
          Symptom: require-mppe-128 option is set, and debug logs contain this sequence:

          sent [CCP ConfReq id=0x1 <mppe +H -M +S +L -D -C>]
          rcvd [CCP ConfReq id=0x4 <mppe +H -M -S -L -D +C>]
          MPPE required but peer negotiation failed
          sent [LCP TermReq id=0x4 "MPPE required but peer negotiation failed"]

          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);

            1. using a later version of pppd that is not so pedantic, and will negotiate further to achieve encryption (a fix was made in revision 1.49 of file pppd/ccp.c in PPP CVS as the solution to closed Debian bug 294232 but is not yet released by the PPP project ... so you can upgrade to PPP CVS or apply the patch in the bug report), or

            2006-03-09
            1. removing the require-mppe-128 option from the file /etc/ppp/options.pptp and any other options given to pppd, if you are content with not using encryption (which can be risky),

            2. configuring the peer to require encryption.

            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:

            Disabling 40-bit MPPE; MS-CHAP LM not supported
            sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
            rcvd [CCP ConfNak id=0x1 <mppe -H -M -S +L -D +C>]
            MPPE required but peer negotiation failed
            sent [LCP TermReq id=0x3 "MPPE required but peer negotiation failed"]

            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

          2. 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

          3. 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.

            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:

            # 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. Linux kernel 2.6.15 or later include the module already. If you've used a patch, 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 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

          4. Received bad configure-ack
            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

          5. LCP ConfNak id=0x1 <mru 1500>
            Problem: the peer persists in refusing an MRU value other than 1500, eventually sending a bad configure ack, as per the following log:

            rcvd [LCP ConfNak id=0x1 <mru 1500>]
            sent [LCP ConfReq id=0x2 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            rcvd [LCP ConfNak id=0x2 <mru 1500>]
            sent [LCP ConfReq id=0x3 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            rcvd [LCP ConfNak id=0x3 <mru 1500>]
            sent [LCP ConfReq id=0x4 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            rcvd [LCP ConfNak id=0x4 <mru 1500>]
            sent [LCP ConfReq id=0x5 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            rcvd [LCP ConfNak id=0x5 <mru 1500>]
            sent [LCP ConfReq id=0x6 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            rcvd [LCP ConfRej id=0x6 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            sent [LCP ConfReq id=0x7]
            rcvd [LCP ConfAck id=0x7 <asyncmap 0x0> <magic 0x7b4d8db> <pcomp> <accomp>]
            Received bad configure-ack: 02 06 00 00 00 00 05 06 07 b4 d8 db 07 02 08 02

            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

        Running pppd (after connection)

        • 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.

        • Protocol-Reject for unsupported protocol 0x????
          See below.

        • LCP ProtRej id=0x??
          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 pppdreading 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

        • 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.

        • RTNETLINK answers: File exists
        • huge transmit data counters
        • 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 debug 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. We list some possible reasons and actions that can be taken:

          Possible ReasonAction
          1. the defaultroute option was used, causing pppd to add a new default route that overrides the existing default route that was used to initiate the tunnel.remove defaultroute from the options given to pppd, and use other means to provide routes through the tunnel interface.
          2. distribution specific or local interface-up scripts changed the route.change or remove the scripts so that they do not change the route in this manner.
          3. the PPTP Server may have failed to provide an IP address, causing the new interface to have the same address as the default address on your host (compare "local IP address" in the logs, or the address shown by "ifconfig ppp0" with the address of your main network interface).add the noipdefault option.
          4. 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 topptp).try one of the following:

          1. change the point-to-point IP address of the newly created ppp interface, using an ip-up or ip-pre-up script, for example;

            #!/bin/sh
            # $1: interface-name
            # $4: local-IP-address
            # delete the assigned address from the network device
            ip addr del $4 dev $1
            # add back the assigned address along with a replacement peer address
            ip addr add $4 peer 10.0.0.1/32 dev $1
            # add a default route, remove if not wanted
            route add default $1

          2. change the point-to-point IP address of the newly created ppp interface, using ifconfig, for example;

            ifconfig ppp0 pointopoint 10.0.1.1

            where 10.0.1.1 is the address to be adopted, see internal address for how to determine this.

          3. 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.

          4. 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)

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

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

          2004-04-06

        • 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]

        • 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: 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 likeifconfig 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.

        • 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.

        • Terminating on signal 2
          Problem: when stopping a tunnel, there's an endless stream of "Terminating on signal 2" messages.

          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.

        Loading kernel modules

        • init_module: File exists
          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:

          init_module: File exists

          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

        Other Problems

        • Error 629, you have been disconnected
          Problem: a client on Microsoft Windows 98 calling a PPTP server displays an error:

          Error 629
          You have been disconnected from the computer you dialed.
          Double-click the connection to try again.

          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 tcpdumpor 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:

          pptpd: ALL: ALLOW

          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:

          pptpd: 10.: ALLOW

          For more information see:

          [links not recently verified]

          2003-09-04

        Fault Tree

        2. 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

        3. 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

        4. 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

        5. 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.
          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:

          • Firewalls and Gateways

            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.

          • Local Filtering Rules

            The client may be configured to block GRE packets as they arrive, or before they depart. Check your iptables or ipchains configuration.

          • Simultaneous Tunnels via NAT Gateway

            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.

          • PPTP Server Misconfiguration

            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.

        6. 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, as part of PPP 2.4.2 or later, and as a patch to the PPP 2.4.0.

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

        7. Check MPPE in kernel Support
          Make sure the MPPE module can be loaded:

          # 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;

          1. depmod -a was not run after loading a kernel-mppe rpm,
          2. the MPPE module cannot be found in the appropriate /lib/modules directory,
          3. the MPPE module that was found cannot be loaded because of version conflicts,
          1. an old mppe.o file was left around after an upgrade that provided an ppp_mppe.o file (which results in "init_module: File exists" error if the mppe.o module is loaded somehow),
          2003-08-01

          1. the ppp_generic module cannot activate the MPPE module when it finds it needs it, because you are using PPP-MPPE 2.4.0 and the /etc/modules.conf file does not have an entry for alias ppp-compress-18 mppe,
          2. the PPP modules were compiled into the kernel statically (they must be modules for MPPE to work as a module),
          3. the ppp_async module cannot be loaded (although pptp does not use a serial port, the ppp_async module is required for data transfer with the psuedo-tty device).
        8. 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 an 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 three PPP MPPE versions, and their history is shown in the graph below:

        • the earlier one contains code licensed under the OpenSSL license, and was independent of the PPP project; it is known as PPP-MPPE 2.4.0. (thanks to those who achieved this!) [red]

        • the later one contains code licensed using the BSD license; is part of the PPP project; and is known as PPP 2.4.2 or later. [green]

        • Jan Dubiec's patches to add MPPC support. [blue]

        PPP History Graph

        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 and later

        • 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 pppdoptions relating to MPPE support.

        The following table compares the options between the versions.

        PPP-MPPE 2.4.0 optionPPP 2.4.2 optionExplanation
        mppe-40require-mpperequire-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-128require-mppe
        mppe-statelessnomppe-statefulStateless is now the default, you'd have to use mppe-stateful to turn it off.
        require-chapms-v2refuse-pap refuse-chap refuse-mschap refuse-eapA 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:

        • in PPP 2.4.2 the packets are decoded fully. Each bit is explained.

        • in PPP-MPPE 2.4.0 the packets are decoded partially, as a series of numbers, four bytes in hexadecimal.

        The following table describes the bits and their meanings:

        PPP-MPPE 2.4.0PPP 2.4.2MeaningExplanation
        0x01000000+HStatelessuse stateless encryption (less vulnerable to packet loss).
        0x00000080+M56-bituse 56-bit key lengths for encryption (not supported).
        0x00000040+S128-bituse 128-bit key lengths for encryption (less easy to decrypt than 40-bit).
        0x00000020+L40-bituse 40-bit key lengths for encryption (more easy to decrypt than 128-bit).
        0x00000010+DObsoleteobsolete, usage unknown.
        0x00000001+CCompressionuse 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.

        What does ConfReq, ConfAck, ConfNak, and ConfRej mean?

        ConfReq
        Proposal        		These options and values are desired.
        ConfAck
        Acceptance        		These options and values are acceptable. The ConfAck reply will contain the options and values.
        ConfNak
        Counter-proposal        		All the options are recognised by the peer, but some of the values in the options are unacceptable. The ConfNak reply will contain the options that were unacceptable, but with values that are acceptable.
        ConfRej
        Rejection        		The options are not recognised or not acceptable for negotiation by the peer (e.g. because the remote system is configured to not allow negotiation). The ConfRej reply will contain only the options that are unacceptable.

        On receipt of a ConfRej, the local system must not include the options in any following ConfReq.

        As James Carlson wrote to the linux-ppp mailing list:

        • Note that the *only* time you can send Configure-Nak is when you actually recognize all of the options (i.e., you *could* have sent Configure-Ack), but some of the values embedded in the options are themselves unacceptable. Configure-Nak says "yes, I like this option, but if you would please just say you want two slots instead of three, I'd be happy." Configure-Reject says "no, I've never even heard of this option; please don't ask me anything else about it."

        See also the PPP RFC 1661.

        2004-02-18

        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 may 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.

        Start tcpdump in one window:Then run pppd in the other window:
        # tcpdump -i eth0
        # pppd call tunnel

        The tcpdump command should show you the packets as they are received or transmitted. Press Control/C when you do not need to capture any more packets.

        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.

        Note: if you get an error:

        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.

        The above technique is useful for quick checking, but for detailed analysis a binary tcpdump is required.

        Security Warning
        Internet addresses of your client and server, usernames and passwords are included in a binary tcpdump. This information may allow someone to gain equivalent access to protected networks. If you do not want to give away this information, convert it to text and remove it before sending the log to someone else.

        If you have been asked to capture a complete tcpdump packet trace, for analysis by someone else, you should:

        • add -w file to tell it to save the packets to the file file,
        • add -s 0 to capture all of each packet,
        • and add tcp port 1723 or proto 47 to keep only the PPTP packets, if the client is performing other network traffic at the time.
        For example:

        # tcpdump -i eth0 -w my.tcpdump -s 0 tcp port 1723 or proto 47

        Again, once the packets have been collected, use Control/C to stop the tcpdump process. The file containing the packets can then be e-mailed or analysed.

        You may analyse it using ethereal.

        # ethereal my.tcpdump

        Note: when using ethereal, clicking on a byte in the hex dump will highlight the field name of the data in the packet, and vice versa. You may also analyse it usingtcpdump:

        # tcpdump -n -r my.tcpdump > my.tcpdump.txt

        This converts it to text, saving the output into a file my.tcpdump.txt. This often hides the username and password. You may wish to globally substitute the IP addresses. Check your results to ensure your security.

        2003-10-21

        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
        pptpconfigclick 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.

        pptp-php-gtk
        pptp-command startstart 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 thatpptp-command created for you.

        pon tunneladd
        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.

        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.

        How to enable pptpd debug logging via syslogd?

        For users of  pptpd, the PPTP server program:
        1. add the keywords debug dump to the /etc/ppp/options.pptpd or /etc/ppp/pptpd-options file, (this is an option for pppd, so there is no need to restart pptpd, the next connection will use the new keywords),

        2. test that syslogd is reporting debug class messages, using the logger command:

          # logger -p daemon.debug some unique test message

          You should see some unique test message added to a log file in the /var/log directory. If no output appears edit /etc/syslogd.conf and add a debug entry, such as:

          1. add the debug entry:

            # PPTP debug logging
            *.debug;mail.none /var/log/debug

          2. touch /var/log/debug

          3. restart syslogd:

            /etc/init.d/sysklogd reload

          Note: this is usually needed on Red Hat derived distributions, because debug logging is disabled.

        3. retry the tunnel, and examine the debug log file,

        4. remove debug once you've fixed the problem, as the logs may cost a lot of disk space and performance.
        Derived from  a post by Peter Mueller.

        How to start a tunnel on demand?

        The tunnel can be started in a way that will wait for the first packet to be sent before it establishes the connection to the server. This is called "demand" mode. See our diagram for how it works.

        Demand mode is handled by PPP, not by PPTP Client. You must start the tunnel using the pppd command rather than pptp. To enable demand mode, add thedemand option to the pppd command, or the /etc/ppp/peers/tunnel file.

        If PPP complains that a connect script is required (versions prior to about 2003-07-01 do this) then add the option connect /bin/true.

        If you normally have to define specific routes to have the tunnel work to your satisfaction, you will have to define these routes once the PPP interface for the tunnel is created, even though the tunnel is not yet connected. Otherwise, packets that should start the tunnel will be sent out the normal interface instead of the tunnel interface.

        The persist option can also be used. This causes the tunnel to be retried if it disconnects. Also check the maxfail option, as the default (10) usually causes the tunnel to eventually stop. Use 0 to say that it should never give up, but remember that this could cause huge amounts of data flow over a long time if the tunnel ever fails in a way that causes PPP to keep trying.

        The pptpconfig GUI cannot be used for demand mode, as of 2003-07-30, because it does not set up the routes before starting the pppd process, and it does not show the log of the connection attempt until it succeeds. However, despite these restrictions, if you wish to try it, type demand in the Options for pppd field on theMiscellanous tab, then start the tunnel.

        2003-07-30

        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.

        Note: this was last updated for PPP-MPPE 2.4.1, which had debugging code for determining where the username and password information was obtained from, and used the old style of MPPE option reporting. PPP 2.4.2 and later generates slightly different output.

        # 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), status = 0x0

        http://pptpclient.sourceforge.net/howto-diagnosis.phtml#confreqacknakrej


        bytxl
        关注
        • 0
          点赞
        • 踩
        • 8
          收藏
          觉得还不错? 一键收藏
        • 0
          评论
        专栏目录
        pptp模块 python_PPTP 在Centos 7.1 建立方法与失效处理
        weixin_35750953的博客
        01-17 698
        # yum install pptp pptp-setuppptpsetup --create vpn --server (serverName) --username (Username) --password (Ps) --start但是执行的时候没有正确的返回：查了message log:Jan 1 21:43:03 localhost pppd[25235]: Connect: p...
        PPTP协议详解及报文解析.doc
        08-19
        PPTP协议详解及报文解析.doc
        linux PPTP
        假不假，生来只为写代码
        08-31 525
        虽然没有调试通过pptp，但是调PPTP的几个步骤大概是这样子 1.建立相关PPTP的配置，可以使用下面的命令 sudo pptpsetup --create pptp --server wandersky.xicp.net --username test --password wWuWmL --start --encrypt 2.上面命令执行后，会修改2个文件， /etc/ppp/peers/pptp 这个pptp是上面命令新建立了。 /etc/ppp/chap-secrets 上...
        pptp流量分析之搭建pptp测试服务器
        kawhiyu的博客
        03-21 1151
        ubuntu搭建pptp服务器，分析pptp流量
        openGauss数据库运维:常见故障定位案例：强制结束指定的问题会话
        最新发布
        weixin_53596073的博客
        06-03 307
        显示类似如下信息，表示用户正在尝试结束当前会话，此时仅会重连会话，而不是结束会话。有些情况下，为了使系统继续提供服务，管理员需要强制结束有问题的会话。postgres为需要连接的数据库名称，8000为端口号。显示类似如下信息，其中pid的值即为该会话的线程ID。从当前活动会话视图查找问题会话的线程ID。显示类似如下信息，表示结束会话成功。以操作系统用户omm登录主机。使用如下命令连接数据库。根据线程ID结束会话。
        PPTP无法连接,PPTP连接错误代码及解决方案
        weixin_33777877的博客
        07-24 5554
        　　PPTP无法连接是大家经常遇到的问题.连接不上PPTP一般都会提示一些错误代码.其实我们可以通过这些错误代码来解决一些简单的问题. 　　本篇文章会给大家简单的介绍几个常见的PPTP错误代码以及对应的解决方案.这里错误代码解决方案会时时更新. 　　807错误–无法连接到服务器.请检查你连接的这条线路是否能ping的通,ping通的情况下是否丢包严重.一般线路不通或者丢包会出现此错误提示.常见于P...
        centos搭建PPTP
        王半仙儿的博客
        01-06 1407
        安装所需要的软件包 yum install -y pptpd 配置PPTP options设置 vi /etc/ppp/options.pptpd 使用下面配置 name pptpd #refuse-pap #refuse-chap #refuse-mschap require-mschap-v2 require-mppe-128 proxyarp #debug lock
        PPTP通用拨号器.zip
        06-23
        通用的pptp拨号器，输入服务器地址，账号，密码就可以连接，非常方便的电脑换IP软件。
        PPTP详解，环境搭建，抓包分析，破解
        05-30
        对PPTP的详细分析，从基础开始搭建环境，附带抓包进行分析 基于信息对密码进行破解
        pptp协议分析
        12-09
        便于详细了解整个认证过程。对于初学者，可以按照上述步骤分析整个加密过程。
        centos 搭建 pptp server
        01-07
        1.先安装ppp, pptpd yum install -y epel-release yum install -y ppp yum install -y pptpd 2.修改 /etc/pptpd.conf   设置拨号连接的地址池, localip 172.168.0.1 remoteip 172.168.0.2-200 ...
        PPTP.ppp.zip
        02-10
        在macos10.15+的系统中，shimo中支持PPTP所需的PPTP.ppp文件，还有另一个pptp文件请看另一个资源。
        pptp.rar_PPTP_vc pptp
        09-14
        pptp_1.7.1的源代码,提供参考学习.
        pptp电脑版客户端
        08-20
        动态网络技术工具，是一种可以把电脑IP不断变化的客服端
        MacOs PPTP文件
        07-24
        MacOs 缺失的PPTP.ppp 以及pptp文件 惊雷 通天修为天塌地陷紫金锤 紫电 玄真火焰九天玄剑惊天变 乌云 那驰骋沙场 呼啸烟雨顿 多情自古空余恨 手持弯月刃 天地沦陷气吞山河崩
        accel-pptp.rar_PPTP
        09-22
        pptp协议代码，基于mips体系架构，应用于路由器的具体实现。
        Fedora core 2下建立支持MPPE/MPPC的PPTP ×××服务器
        weixin_34010566的博客
        05-09 688
        一、简介 前段时间笔者写了一篇《Fedoracore2下建立Poptop服务器以及常见问题》的文章，收到许多朋友的欢迎，但是那篇文章只支持MPPE数据加密，不支持MPPC数据压缩，未免有些遗憾，所以笔者再接再厉阅读了一些文档，终于使PPTP×××实现了MPPC数据压缩功能。首先我们先来介绍一下MPPE/MPPC的概念。 MPPE：MicrosoftPoin...
        linux下连接windows2003 ppoe 服务器
        weixin_34092370的博客
        10-11 539
        1，在CentOS6.3下用 /usr/sbin/pppd pty "/usr/sbin/pptp publicip --nolaunchpppd" file /etc/ppp/options.pptp user user1 password password1 再用tail -f /var/log/messages看到log如下 Oct 8 03:25:41 ...
        解决PPTP客户端拨号不成功
        D0126_的博客
        12-13 1200
        PPTP
        pptp server nat
        05-27
        在设置PPTP服务器时，如果您的服务器不在公共IP地址上，您需要使用NAT（Network Address Translation）来使PPTP服务器能够通过Internet连接。以下是如何在PPTP服务器上设置NAT： 1. 确保您已经启用了IP转发功能。您可以通过编辑/sysctl.conf文件并将以下行添加到文件末尾来启用它： ``` net.ipv4.ip_forward=1 ``` 2. 安装并配置iptables软件包以启用NAT。以下是一个示例iptables规则： ``` iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE ``` 其中，eth0是您的Internet连接接口的名称。这条规则将为通过PPTP服务器连接到Internet的所有客户端启用NAT。 3. 确保PPTP服务器的配置文件中正确设置了“localip”和“remoteip”行。这些行应设置为您的服务器的本地IP地址和分配给PPTP客户端的IP地址范围。 4. 重新启动PPTP服务以使更改生效，例如：“service pptpd restart”。 请注意，启用NAT可能会影响您的网络安全，因此请确保仅向可信用户公开您的PPTP服务器。

        “相关推荐”对你有帮助么？

        • 非常没帮助
        • 没帮助
        • 一般
        • 有帮助
        • 非常有帮助
        提交
        评论
        添加红包

        请填写红包祝福语或标题

        个

        红包个数最小为10个

        元

        红包金额最低5元

        当前余额3.43元 前往充值 >
        需支付：10.00元
        成就一亿技术人!
        领取后你会自动成为博主和红包主的粉丝 规则
        hope_wisdom
        发出的红包
        实付元
        使用余额支付
        点击重新获取
        扫码支付
        钱包余额 0

        抵扣说明：

        1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
        2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

        余额充值