Last Updated: 1999/10/11 (by Jeff Blaize <jblaize@netops.mediaplex.com>
Send changes to: Daniel Djamaludin <danield@snapgear.com>

HOWTO/FAQ mostly compiled from PoPToP help pages and the PoPToP Mailing List (hosted by Christopher Schulte) by Matthew Ramsay. Large contributions from Steve Rhodes and Michael Walter.

1.0 Introduction

1.1 About PoPToP

PoPToP is the PPTP Server solution for Linux. PoPToP allows Linux servers to function seamlessly in the PPTP VPN environment. This enables administrators to leverage the considerable benefits of both Microsoft and Linux. The current pre-release version supports Windows 95/98/NT/2000 PPTP clients and PPTP Linux clients. PoPToP is free GNU software.

PoPToP Home Page: http://www.poptop.org

1.2 Credits

PoPToP was originally started by Matthew Ramsay under the control of Moreton Bay Ventures (http://www.moretonbay.com). Around March 1999 PoPToP was publicly released under the GNU GPL by Moreton Bay.

PoPToP is what it is today due to the help of a number of intelligent and experienced hackers. More specifically Kevin Thayer, David Luyer and Peter Galbavy.

More contributors to PoPToP (in various forms) include Allan Clark, Seth Vidal, Harald Vogt, Ron O'Hara and Chris Wong.

And finally, credit to all the PoPToP followers who test and report problems.

2.0 System Requirements

  1. A modern Linux distribution (such as Debian, Red Hat, etc.) with a recent kernel (2.2.x recommended, 2.0.x should be ok). Note: ports exist for Solaris, BSD and others but are not supported in this HOWTO at this time.

  2. PPP 2.3.8 (and the MSCHAPv2/MPPE patch if you want enhanced Microsoft compatible authentication and encryption).

    Actually, any pppd version of 2.3.x will work just fine for tunnelling. However, if you want to take advantage of MSCHAPv2/MPPE (Microsoft's "PPTP version 2"), which fixes most of the blatant security holes found in Microsoft's MSCHAPv1/LanMAN (MS PPTPv1), you will need the source code tarfile of pppd version 2.3.8 or 2.3.10 to apply patches and recompile. You will also need the source code for a 2.2.x kernel, and a SSLeay crypto source tree as well. These are discussed in detail below.

  3. PoPToP v1.0.0 (or download the latest release at: http://www.poptop.org

3.0 PPP (and MSCHAPv2/MPPE) Installation

It is only necessary to use PPP 2.3.8 if you want Microsoft compatible MSCHAPv2/MPPE authentication and encryption. The reason for this is that the MSCHAPv2/MPPE patch currently supplied (19990813) is against PPP 2.3.8. If you don't need Microsoft compatible authentication/encryption any 2.3.x PPP source will be fine.

Assuming you want Microsoft compatible authentication/encryption follow these steps:

  1. Grab yourself a clean copy of the PPP daemon v2.3.8 (ppp-2.3.8.tar.gz). I usually go here for my PPP files: ftp://cs.anu.edu.au/pub/software/ppp/ Note: You must get the tarball (tar.gz) and *not* the RPM.

  2. Grab yourself the MSCHAPv2/MPPE diff file from: http://www.moretonbay.com/vpn/releases/ppp-2.3.8-mppe-others-norc4_TH7.diff.gz

  3. Grab yourself the SSLeay-0.6.6b file from: ftp://ftp.psy.uq.oz.au/pub/Crypto/SSL/SSLeay-0.6.6b.tar.gz

  4. You should now have 3 files:

    Copy these files to your preferred location (I prefer /usr/local/src/).

  5. Assuming your newly retrieved source files are in /usr/local/src/ and your current working directory is also /usr/local/src/ do the following:
    	tar zxvf ppp-2.3.8.tar.gz
    	gunzip ppp-2.3.8-mppe-others-norc4_TH7.diff.gz
    	tar zxvf SSLeay-0.6.6b.tar.gz
    	cp SSLeay-0.6.6b/crypto/rc4/rc4.h ppp-2.3.8/linux/
    	cp SSLeay-0.6.6b/crypto/rc4/rc4_enc.c ppp-2.3.8/linux/
    	patch -p0 < ppp-2.3.8-mppe-others-norc4_TH7.diff
    	cd ppp-2.3.8

  6. The files should now all be in place and we are ready to compile PPP. Follow these steps to compile it:
    	cd linux
    	cd ..
    	cp pppd/pppd /usr/sbin/
    	cd /usr/src/linux
    	make modules SUBDIRS=drivers/net
    	make modules_install
    	rmmod ppp
    	insmod ppp
    	insmod ppp_mppe

  7. The new PPP daemon should now be correctly installed. You now need to update some of your configuration files: Here is an example PPP options file (/etc/ppp/options):

    Here is an example chap-secrets file (/etc/ppp/chap-secrets)
    	username * password *

4.0 PoPToP Installation

Follow these instructions to install PoPToP:

  1. Grab the latest version of PoPToP (v1.0.0 as of 19991001) (http://www.poptop.org)

  2. You will need to be root to install and run PoPToP.

  3. If you downloaded the PoPToP v1.0.0 tar file (and stored it in /usr/local/src/) follow these instructions:
    	cd /usr/local/src/
    	tar zxvf pptpd-1.0.0.tgz
    	cd pptpd-1.0.0
    	make install
  4. If you downloaded the PoPToP RPM (pptpd-1.0.0-1.i386.rpm as of 19991001) follow these instructions:
    	rpm --install pptpd-1.0.0-1.i386.rpm
  5. >Note: PoPToP's binaries are located in /usr/local/sbin. PoPToP goes looking for its binaries in that directory! So if they are not there it won't work! Check that there is 'pptpd' and 'pptpctrl' in /usr/local/sbin/ now.

  6. If you want to enable debugging follow these steps: Change directory to /etc/ and open up syslog.conf. Add the line: daemon.debug /var/log/pptpd.log Kill off the current syslogd and start a new one:
    	killall syslogd
  7. Make sure the following files exist and look similar to:
    	name servername
    	speed 115200
    	billy   servername      bob     *
  8. You are now ready to launch PoPToP. If you want to launch PoPToP now:

    Note: If you can't connect for some reason open up /var/log/pptpd.log and search for any error messages. If that doesn't help read the FAQ (below) or as a last resort send a message to the mailing list.

5.0 Windows Client Setup

Install the Windows Virtual Private Networking support using the Add/Remove Programs tool in Control Panel. In that utility go to the Windows Setup tab, and goto Communications. Check the box for Virtual Private Networking.

(If you do above you may *not* need to follow the instructions below as it will already be installed... ?)

follow the instructions:

  1. start->settings->control panel->network
  2. Click add
  3. choose adapter
  4. Click add
  5. select microsoft as the Manufacturer
  6. select Microsoft Virtual Private Networking Adapter
  7. Click ok
  8. Insert any necessary disks
  9. Reboot your Machine

take a little nap here...

Once your Machine is back

  1. go to dial-up networking (usually start->programs->Accessories->communications->Dial-up Networking) YMMV
  2. Click make new connection
  3. Name the Connection whatever you'd like.
  4. Select Microsoft VPN adapter as the device
  5. click next
  6. type in the ip address or hostname of your pptp server
  7. click next
  8. click finish
  9. Right-click on the intranet icon
  10. select properties
  11. choose server types
  12. check require encrypted password
  13. uncheck netbeui, ipx/spx compatible
  14. click tcp/ip settings
  15. turn off use IP header compression
  16. turn off use default gw on remote network
  17. click ok.
  18. start that connection
  19. type in your username and pw (yadda, yadda, yadda)
  20. once it finishes its connection your up.

Note that the Win95 routine is similar but requires Dial Up Networking Update 1.3 (free from Microsoft) to be installed first.

6.0 Setup Notes

6.1 Introduction

After spending the better part of two weeks developing my configuration for a pptp sever for remote file access by Windows(tm) clients, I thought I would pass along these notes to those who may be interested.

The basic configuration involves a Samba/PoPToP server behind a firewall, through which clients using Win98 machines will connect using the VPN facility built into that OS. This is diagrammed below.

 _____         ___         ______        ______
|     |       |   \       | fire |      | file |
| win | ---> / net \ ---> | wall | ---> | srvr |
|_____|      \__/\_/      |______|      |______|

The components of the system consist of the Win98 clients running the built-in VPN facility dialing in to their ISP's and connecting through the firewall to the Samba server on the internal network using the pptp protocol. The firewall uses Network Address Translation to convert an open Internet IP address to an internal one. Sounds simple enough right?

6.2 Simple Test Setup

As a starting point, I configured a Win98 box to connect directly to a PoPToP server without any authentication or encryption. This was just to get a feel for how pptp works and verify the setup. Using the pre-packaged rpm's was a big help here. You just rpm the thing onto the system and fire it up, and you're in business. The diagram below represents this simple system.      
   _____                        ______
  |     |                      | file |
  | win | ------------------>  | srvr |
  |_____|                      |______|

Emboldened by my success, I set out to turn on MS authentication and encryption, and this is where the fun started.

6.3 Authentication and Encryption

This is an area where Microsoft really shows its true colors. Turning on password and data encryption on the Win98 VPN server configuration was quite the eye opening experience. First with the authentication, you will have to go through a somewhat difficult compilation of the ppp-2.3.8 package. The worst part here is getting all the pieces together, namely the rc4 files. This process is well documented in this archive, so I won't go into it here.

The next realization is that Microsoft prepends the domain name to the user name when submitting the login credentials. For example, srhodes is now DBNET\\srhodes. If that wasn't bad enough, I found that the domain wasn't even the one I was logged into. My best guess is that the first domain that the computer ever logs into is stuck with it for ever. This is a real problem if you have multiple domains that you log into. I modified the pppd.c code to strip out the domain on MSCHAP logins, but you can just set the user name in chap-secrets to match the windows version.

Then I spent a whole day trying to figure out why data encryption does not work. I tried just about everything I could think of that could be wrong. That's when I discovered this archive, for which I am truly grateful. It turns out that the Win98 implementation of encryption is FUBAR! You have to download one of those patches from Microsoft, DUN40.exe to get the thing to work. This is for 40 bit encryption. Don't hold your breath waiting for 128 bit.

6.4 Linux Firewall Configuration (ipchains)

The issue with a firewall in this setup is that you need to cover two types of protocol communication. There is one connection which is a tcp connection on port 1723 that handles the control functions and another connection using IP type 47, or GRE, which handles the actual data communication. This second connection presents a problem for the convention linux firewall, ipfwadm. You see, its only set up to handle tcp, udp and icmp protocols. It doesn't know about GRE.

The trick around this block is to use one of the new 2.2 kernels, which employ a new firewall called ipchains. This tool willl handle arbitrary protocols, which can be specified by their numbers.                          
   _____                   ______                   ______
  |     |                 | fire |    | file |
  | win | --------------->| wall | --------------> | srvr |
  |_____| |______|                 |______|

You need to remember a few things before getting too deep into this. The default gateway on win is set to, and the default gateway on file srvr is set to The firewall has the two network interfaces spanning the two subnets and is configured for IP forwarding. If you have not yet applied any firewall rules, this configuration will work as before. The interesting part is to block out all other access to file srvr by implementing ipchains rules.

The short story is:
ipchains -F
ipchains -P forward DENY
ipchains -I forward -p tcp -d 1723 -j ACCEPT
ipchains -A forward -p tcp -s 1723 -j ACCEPT
ipchains -A forward -p 47 -d -j ACCEPT
ipchains -A forward -p 47 -s -j ACCEPT

6.5 Linux Network Address Translation (NAT)

The next hurdle is to configure the firewall so that it can run an open internet IP address on the outside and allow access to an internal address on the inside. NAT is very well suited to this task, although you may hear otherwise from knowledgeable sources. It happens to be my preference, though certainly not the only way to skin this cat. You can obtain the NAT software and some detailed information from

But again, there is a problem with the GRE protocol of type 47. The tool for configuring NAT, ipnatadm, like its half-brother ipfwadm, is not set up to handle arbitrary protocols. Unfortunately, you'll have to go into the code and make a slight modification if you want to use it for this purpose. There is a procedure called parse_protocol in the file routines.c that discriminates the type of protocol to be filtered. The basic idea is to accept a string representing a number and use that as the filter. Since you have to recompile the kernel anyway to get the NAT functionality, maybe it's not so horrible, relatively speaking.

For those ambitous enough, here is the diff for the routines file, copy this into a file called routines.diff and use the command patch -p0 < routines.diff from within the same directory.

--- routines.c  Thu Mar 25 15:41:58 1999
+++ /mnt/zip/nat/routines.c     Wed Jul 21 21:09:28 1999
@@ -112,11 +112,18 @@
        else if (strncmp("icmp", s, strlen(s)) == 0)
                nat_set.nat.protocol = IPPROTO_ICMP;
        else {
+               int number;
+               char * end;
+               number = (int)strtol(s, &end, 10);
+               nat_set.nat.protocol = number;
+       }
+       /*
+       else {
                fprintf(stderr, "ipnatadm: invalid protocol \"%s\"
specified\n", s);
-               /* make the compiler happy... */
+       */

 void parse_hostnetworkmask(char *name, struct in_addr **addrpp, __u32
*maskp, int *naddrs)

The patch is actually lifted from ipchains, which was derived from ipfwadm, which provides the basis for ipnatadm.

Once you've got all that running, what you want to do is to set up the NAT rules so that the incoming client thinks its talking to the firewall, as does the outgoing file server. The short of it is:

ipnatadm -F
ipnatadm -I -i -P 6 -D 1723 -N 1723
ipnatadm -O -i -P 6 -S 1723 -M 1723
ipnatadm -I -i -P 47 -D -N
ipnatadm -O -i -P 47 -S -M

Here, the -P argument sets the protocol, 6 is tcp and 47 is GRE. PPTP packets targeting the firewall are translated to the internal host inbound and vice-versa on the way out. Very slick.


Here's a subject so complex you could probably devote a whole career to it. We don't want to get too bogged down, so I'll be brief. Samba implements the NetBIOS protocol, which has more quirks than you can shake a stick at. One of the biggest problems is the use of subnet broadcasting. Suffice it to say, if you want the best results, you should set your PoPToP IP addresses to reside within the subnet on which the file server ethernet is located. I choose for the server address, and it hands out IP's from 192.168.13-127. Setting the IP forwarding on the file server to true will give you access to other machines on the internal network.

When you go at the samba sever from Win98, you have to use encrypted password. Look at smbpasswd and related stuff.

Finding shares on the server is not so easy. The short story here is that browsing is implemented via broadcast packets, and broadcast packets will not travel down a PPP link. The only way to get browsing to work over pptp is to set Samba up as a WINS server and a Domain login server, and configure the clients to use that WINS server and force them to login to that Domain. Believe me, I tried just about everything to avoid that. You will also want to set the samba server as the domain master and preferred master for the browsing.

If you can't do that, you can set the ppp/options file to include a ms-wins setting for the samba server. This will set the client up so they can at least resolve host names. The only way to find a share under this configuration is to name it explicitly. You can use the tools menu from the Win98 file browser and say find -> computer and enter in the name of the samba server and it will be found. I have found that setting domain master = yes and preferred master = yes gives a rather nice boost to the speed of name lookups on the network.

Here is my abbreviated smb.conf

   workgroup = VAULT
   server string = acer
   log file = /var/log/samba/log.%m
   max log size = 50
   security = user
   encrypt passwords = yes
   smb passwd file = /etc/smbpasswd
   socket options = TCP_NODELAY
   domain master = yes
   preferred master = yes
   domain logons = yes
   wins support = yes
   dns proxy = no
   comment = Home Directories
   browseable = no
   writable = yes

You should also use the lmhosts option for nmbd (-H) and set up an lmhosts file on the samba server. Make sure also the the samba server can resolve its own name, through either /etc/hosts or DNS.

In all honesty , I went through the same simple test setup with samba as I did for PoPToP, although its not shown here explicitly.


PoPToP is a good program, as is Samba. This configuration can work if you put a little effort into it. I have seen a lot of questions here and in other places about these types of systems, so I would think that there is some demand on the part of users who want this type of functionality. I hope these notes are useful to you if this is what you want to do.

7.0 FAQ

Q. I have a pptp server set up on my office LAN. I can connect to the server and ping to it fine, but I can't ping any other hosts on the office subnet. I have ip-forwarding turned on and I have proxyarp set in the ppp/options file. What can be wrong?


There seem to be a lot of questions floating around about routing and masq'ing associated with this issue.

Well, my curiosity got the best of me, so I thought I would check this out. Shown below is my test setup for investigating this problem.
 ________          _______           ______        _____
|        |        |       |         |      |      |      |
| client |------->| fire  |-------->| pptp |----->| host |
|        |        | wall  |         | srvr |      |      |
|________|        |_______|         |______|      |______|
    H                                   H
    H              H
    H                                   H
    H===================================H     pptp connection

For the sake of simplicity, we will ignore address translation issues associated with the firewall. This assumes that the client at is going to use as its target address for the pptp connection to pptp_srvr. The firewall will block all access to

the subnet except for pptp connections associated with pptp_srvr. This can be implemented with ipchains

ipchains -P input DENY
ipchains -P forward DENY
ipchains -A input -j ACCEPT    /* allow connections from

inside */
ipchains -A input -p tcp -d 1723 -j ACCEPT
ipchains -A input -p 47 -d -j ACCEPT
ipchains -A forward -p tcp -d 1723 -j ACCEPT
ipchains -A forward -p tcp -s 1723 -j ACCEPT
ipchains -A forward -p 47 -d -j ACCEPT
ipchains -A forward -p 47 -s -j ACCEPT

When you connect from client to pptp_srvr, you will be able to complete the connection and ping to pptp_srvr. However, if you attempt to ping host, at, this will fail.

A clue to this problem can be found in the /var/tmp/messages file on pptp_srvr. There, in the pppd messages, you will find

Cannot determine ethernet address for proxy ARP

This is due to an issue with the pppd program, which attempts to find a hardware interface on the subnet to which the pppd client has been assigned. In this case its looking for a hardware interface on the subnet. It will fail to find one, and will drop the proxyarp request.

The simplest way around this problem, and the one that is suggested in the pppd documentation, is to set the pppd client IP assignment to be on the local subnet. An example in this case might be However, it may not be possible to do that. In the case of a fully loaded subnet, there may not be any addresses to spare. Or there may be some security issues with giving out local subnet addresses. What to do?

The place to look is in the arp table. If you run tcpdump on host ( during the time when client is pinging, you will see unanswered arp requests from host attempting to find the hardware address for You need to proxy the hardware address of the pptp_srvr for client in order for this request to be fulfilled. This is the job of proxyarp. However, proxyarp has let us down in this instance, and we need to find a workaround.

This can be done manually using the arp command on pptp_srvr. For example, if the hardware address of the ethernet card on pptp_srvr is 00:60:08:98:14:14, you could force the arp to proxy the client pptp address by saying

	arp --set 00:60:08:98:14:13 pub

You should now be able to ping from client to host through the pptp connection.

This can be a problem, however, in a dynamic environment when clients are logging into and out of the pptp server on a continuous basis. One way around this problem is to write a script that will execute upon the initiation of each ppp connection.

The place to do this is in /etc/ppp/ip-up. This script is executed each time a new ppp connection is started. It gets some variables passed into it, one of which is the assigned IP address of the client. Note that RedHat systems use ip-up.local as the place for you to make the script. Don't forget to chmod +x !

#! /bin/bash


date > /var/run/ppp.up
echo "REMOTE_IP_ADDRESS = " $REMOTE_IP_ADDRESS >> /var/run/ppp.up
arp --set $REMOTE_IP_ADDRESS 00:60:08:98:14:14 pub >> /var/run/ppp.up

exit 0

This should put you in business for accessing the remote subnet under this scenario. I am a little bit concerned, however, because I also built a script ip-down.local, that should remove the arp proxy when client disconnected. It doesn't seem to do anything, however, and if I try to delete the arp entry manually, it just spits out a cryptic error message. The arp entries remain persistent, as far as I can tell. If this is a problem or not, I don't know. The next few clients that log in are treated well, so I guess its OK.

Q. Also, after running pptpd and monitoring its log file and seeing that it failed to open ttyp1 - I chmod +rw /dev/ttyp[0-9] and it seemed to work somewhat. But, after I rebooted, I had to do this again. Is this normal?

A. pptpd should be running as root (unless you have a system with a setuid openpty() helper, which isn't very common). If it fails to open a pty/tty pair as root then that is probably because it is in use.

Other programs which use pty/tty's will change their permissions back to the standard ones.

Q. Sometimes when I make a connection to my pptpd server I see a message like

Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-21
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-26
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-24
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-21
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-26
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-24
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-26
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-24
Jul  2 17:30:03 ape modprobe: can't locate module ppp-compress-21
in /var/log/messages on the server. Any idea what I can do about it?

A. Yeah, in your /lib/modules//net/ directory, there should be files called bsd_comp.o and ppp_deflate.o.. insmod those files and you'll be good to go.

Q. Hi, I'm having trouble getting pptpd & mschap-v2 to work. I downloaded all of the patches and compiled everything but whenever i try to connect from my win98 machine, it says:

Error 691: The computer you have dialed in to has denied access because the username and/or password is invalid on the domain.

What is this suppose to mean?

A. Error 691 is an authentication problem probably due to the fact that MS chap uses the domain name and username combo to authenticate. If you look at the logs you will probably see a message saying that MS chap is trying to authenticate user "domain\\username". I got it to work by putting the full domain and user string in the client portion of the chap-secrets file.
# Secrets for authentication using CHAP
# client                server          secret          IP
workgroup\\user         server          password         *    

If anyone knows how to get it to default to a particular domain, I would like to know.

Q. How do I go about checking who is logged in via tunnel?

I need some way of writing the pppd data to wtmp/utmp. (and not sessreg either)

does anyone know of any way of doing this via ppp?

A. pppd syslogs everything to /var/log/messages (that's the default on my box anyways) and it will say something like :

	pppd[15450]: CHAP peer authentication succeeded for 

you could do a tail /var/log/messages -n2000 | grep CHAP if you wanted to see who has been logging in.

other than that, there's not much i know of. all the authentication is provided by pppd (if you don't have an auth or a require-chap (or pap, etc.) option, it doesn't even ask for a username.

Q. My NT client won't connect!

A. And try taking header and software compression off.

Q. PPTP *client* stops working.

A. go to /var/run/pptp/ and look for a socket named x.x.x.x delete it and try it again.

Q. How many clients does PoPToP support?

A. The limits under Linux are:

    • per-process filedescriptors
      • one per client (would limit clients to 256 by default, or 1024 with kernel recompile, or more with major libc/kernel hackery)
      • no relevant limit
    • ttys
      • currently, with a standard kernel, 256 clients
      • with Unix98 ptys and a small amount of coding, 2048
    • ppp devices
      • no limit in kernel source for ppp
    • processes
      • 2 per client plus system processes
      • standard kernel max = 512 processes, ie 256 clients
      • i386 max = 4096 processes, ie 2048 clients

      So it seems that 2048 will be the limit, if you fix a few things and with a minor kernel mod (I could do all of these pretty easily and send you a trivial kernel patch). To go above 2048 the easiest approach would be to combine pptpctrl and pppd in one process, which would get you to 4096. Beyond there, you need to go for a select() based model, which would be significant coding effort and require large fd-set sizes and so on. So 4096 is the practical limit, and 2048 the easy limit.

Q. What authentication methods (PAP/CHAP) does PoPToP work with?

A. PoPToP uses whatever authentication methods your PPPd provides (usually PAP and CHAP). With PPPd patches you can get MSCHAP and MSCHAPv2 authentication as well.

Q. When running PoPToP I get the following error:

Jun 11 08:29:04 server pptpd[4875]: MGR: No more free connection slots!
What does this mean?

A. I'd say at a guess you've only configured one IP address and you have connected a client, and as such there are no more free connection slots should any more clients wish to connect.

Q. Does PoPToP suffer from the same security flaws (http://www.counterpane.com/pptp.html) as the Windows NT PPTP server?

A. An initial look at the article suggests that what the authors hammered was not the PPTP protocol, but the authentication that the PPTP VPN servers on NT offered access to via open internet. PPTP seems initially to be just the path to the weakness, not the weakness itself. Part of their observance of weakness deals with use of poor passwords as well, a cheap component, simple enough to fix.

> While no flaws were found in PPTP itself, several serious flaws were
> found in the Microsoft implementation of it.
> (http://www.counterpane.com/pptp-pressrel.html)

The authors do not specifically say "this is ONLY effective against NT", just that NT is affected. This implies that they do not recognize PoPToP, and it may be included. The fact that PoPToP has to interOp with MS DUN's VPN client means that it will have the same weaknesses. It can only protect itself from DoS attacks, have immediate response to out-of-sequence packets or illogical packets, etc.

The protocol is not considered weak in this analysis, but the weaknesses have to be replicated in apparent behavior by PoPToP. The only thing the developers can do with PoPToP is make it a stronger server per se -- more able to handle the attacks when the come.

In conclusion: PoPToP suffers the same security vulnerabilities as the NT sever (this is because it operates with Windows clients).

Update: MSCHAPv2 has been released and addresses some of the security issues. PoPToP works with MSCHAPv2.

Q. Does PoPToP support data encryption?

A. Yes.. with appropriate PPPd patches. Patches are available for PPPd to provide Microsoft compatible RC4 data encryption. The PPPd patch supports 40 and 128 bit RC4 encryption.

Q. PoPToP or IPsec? Which is better suited to my needs?

A. Here are some reasons I can think of:

  1. The difference between PoPToP and IPsec is that PoPToP is ready NOW.. and requires *no* third party software on the Windows client end (Windows comes with a free PPTP client that is trivial to set up).

  2. PoPToP is a completely *free* solution. Update: Unfortunately not true for Mac *clients* though. The Mac client software is around $400 US a copy.
  3. PoPToP can be integrated with the latest PPPD patches that take advantage of MSCHAPv2 and MPPE (Microsoft encryption using RC4 - 40/128 bits).

    More details follow from Emir Toktar:

    (Refs: A Comprehensive Guide to Virtual Private Networks, IBM. Virtual Private Networking: An Overview White Paper - DRAFT, 3/18/98 Microsoft.)

    Neither network layer-based (L2TP, PPTP,...) nor application layer-based (IPSec,SSL,SSH) security techniques are the best choice for all situations. There will be trade-offs. Network layer security protects the information created by upper layer protocols, but it requires that IPSec be implemented in the communications stack.

    With network layer security, there is no need to modify existing upper layer applications. On the other hand, if security features are already imbedded within a given application, then the data for that specific application will be protected while it is in transit, even in the absence of network layer security. Therefore security functions must be imbedded on a per-application basis.

    There are still other considerations: Authentication is provided only for the identity of tunnel endpoints, but not for each individual packet that flows inside the tunnel. This can expose the tunnel to man-in-the-middle and spoofing attacks.

    Network layer security gives blanket protection, but this may not be as fine-grained as would be desired for a given application. It protects all traffic and is transparent to users and applications.

    Network layer security does not provide protection once the datagram has arrived at its destination host. That is, it is vulnerable to attack within the upper layers of the protocol stack at the destination machine.

    Application layer security can protect the information that has been generated within the upper layers of the stack, but it offers no protection against several common network layer attacks while the datagram is in transit. For example, a datagram in transit would be vulnerable to spoofing attacks against its source or destination address.

    Application layer security is more intelligent (as it knows the application) but also more complex and slower.

    IPSec provides for tunnel authentication, while PPTP does not.

    Layer 2 tunneling protocols inherit the user authentication schemes of PPP, including the EAP methods discussed below. Many Layer 3 tunneling schemes assume that the endpoints were well known (and authenticated) before the tunnel was established. An exception to this is IPSec ISAKMP negotiation, which provides mutual authentication of the tunnel endpoints. (Note that most IPSec implementations support machine-based certificates only, rather than user certificates. As a result, any user with access to one of the endpoint machines can use the tunnel. This potential security weakness can be eliminated when IPSec is paired with a Layer 2 protocol such as L2TP.

    Using the Extensible Authentication Protocol (EAP), Layer 2 tunneling protocols can support a wide variety of authentication methods, including one-time passwords, cryptographic calculators, and smart cards. Layer 3 tunneling protocols (IPSec) can use similar methods; for example, IPSec defines public key certificate authentication in its ISAKMP/Oakley negotiation.

    Layer 2 tunneling supports dynamic assignment of client addresses based on the Network Control Protocol (NCP) negotiation mechanism.

    Generally, Layer 3 tunneling schemes assume that an address has already been assigned prior to initiation of the tunnel. Schemes for assignment of addresses in IPSec tunnel mode are currently under development and are not yet available.

    Layer 2 tunneling protocols support PPP-based compression schemes. For example, the Microsoft implementations of both PPTP and L2TP use Microsoft Point-to-Point Compression (MPPC). The IETF is investigating similar mechanisms (such as IP Compression) for the Layer 3 tunneling protocols.

    Layer 2 tunneling protocols support PPP-based data encryption mechanisms. Microsoft's implementation of PPTP supports optional use of Microsoft Point-to-Point Encryption (MPPE), based on the RSA/RC4 algorithm. Layer 3 tunneling protocols can use similar methods; for example, IPSec defines several optional data encryption methods which are negotiated during the ISAKMP/Oakley exchange.

    MPPE, a Layer 2 protocol, relies on the initial key generated during user authentication, and then refreshes it periodically. IPSec, explicitly negotiates a common key during the ISAKMP exchange, and also refreshes it periodically.

    Layer 2 tunneling supports multiple payload protocols, which makes it easy for tunneling clients to access their corporate networks using IP, IPX, NetBEUI, and so forth. In contrast, Layer 3 tunneling protocols, such as IPSec tunnel mode, typically support only target networks that use the IP protocol. IPSec is not multi-protocol.

    IPSec will be suported by Windows 2000.

    Many cases can occur, each of which needs to be examined on its own merit. It may be desirable to employ a mix of both network layer security techniques and application layer techniques to achieve the desired overall level of protection. For example, you could use an upper layer mechanism such as Secure Sockets Layer (SSL) to encrypt upper layer data. SSL could then be supplemented with IPSec's AH protocol at the network layer to provide per-packet data origin authentication and protection against spoofing attacks.

Q. I get a 'createHostSocket: Address already in use' error! what gives?

A. Address already in use in createHostSocket means something is already using TCP port 1723 - maybe another pptp daemon is running?

Q. Does PoPToP work with Windows 2000 clients?

A. PoPToP v0.9.5 and above should work with Windows 2000 clients.