RedHat8PptpServer

work in progress - not sure if this is all right yet...

• install kernel-source rpm
• install ppp-2.4.1-7 rpm

This is a weird one. I think you really need a ppp with the microsoft stuff built in. Use this one: ppp-2.4.2 rpm or this one: ppp 2.4.1-mppe. I used the latter.

ppp version 2.4.2 and later includes the microsoft auth/encryption parts by default.

The failure if you forget to install a good ppp is something like this in your syslog:

pptpd[2418]: GRE: read(fd=5,buffer=804d720,len=8196) from PTY failed: status = -1 error = Input/output error
pptpd[2418]: CTRL: PTY read or GRE write failed (pty,gre)=(5,6)

key troubleshooting tip: start pptpd with the -f switch to keep it in the foreground, then try making your vpn connection. You will see messages from pppd like "unknown protocol chapms-v2". That seems to be the only way to catch this screwup.

• install pptp-1.1.3-4 rpm from www.poptop.org
• download kernelmod-0.6.tar.gz from http://www.poptop.org
• run kernelmod to build a patched ppp module w/ ms encryption stuff:

# kernelmod.sh -k /usr/src/linux-2.4

• modprobe new ppp_generic, ppp_async, and ppp_mppe modules to test them, they should load w/o errors.
• Add the following to /etc/modules:

alias ppp ppp_generic
alias char-major-108 ppp_generic
alias tty-ldisc-3 ppp_async
alias tty-ldisc-14 ppp_synctty
alias ppp-compress-18 ppp_mppe
alias ppp-compress-21 bsd_comp
alias ppp-compress-24 ppp_deflate
alias ppp-compress-26 ppp_deflate
alias net-pf-47 ip_gre

troubleshooting tip: I found that one VPN I set up worked fine when the modules were loaded by hand. However, it failed if you rebooted the system and it tried to load them automatically. The problem was that the kernelmod script puts something in there that turns ppp off. Remove the following:

alias char-major-108 off

at the bottom. This actually prevented ppp from loading. The log error messages were the same as for the case of having an incorrect version of ppp installed - GRE read from PTY failed. That message generally just means that pppd failed to load. Running pptpd with the -f switch will quickly pinpoint these sorts of problems.

• edit /etc/pptpd.conf:

option /etc/ppp/options.pptpd
debug
localip 192.168.14.100
remoteip 192.168.14.101-120

• edit /etc/ppp/options.pppd:

lock
debug
nobsdcomp
proxyarp
chapms-strip-domain patch
chapms-strip-domain
-chap
-chapms
+chapms-v2
mppe-40
mppe-128
mppe-stateless
ms-wins 192.168.14.1
ms-dns 192.168.14.1

note the ms-wins and ms-dns entries send the wins and dns server config info to windows client systems, so you don't have to type it in manually on each client.

• edit /etc/ppp/chap-secrets:

# client        server  secret                  IP addresses
user1           *       password                192.168.14.101
user2           *       password                192.168.14.102

• Add firewall rules to allow gre and pptp control traffic for the vpn:

iptables -t filter -P FORWARD DROP
iptables -A OUTPUT -p 47 -j ACCEPT
iptables -A INPUT -p 47 -j ACCEPT
iptables -A FORWARD -s 192.168.14.0/24 -d 192.168.14.0/24 -j ACCECPT
iptables -A INPUT -p tcp -m tcp --dport 1723 -j ACCEPT

I had to add the following, not sure if it's just due to my specific setup:

iptables -A INPUT -s 192.168.14.0/24 -d 192.168.14.0/24 -j ACCEPT

• Save firewall rules (not sure if this is right)

# /sbin/iptables-save >/etc/sysconfig/iptables

• Start pptp server

# service pptpd start

• Configure your windows client by reading these instructions.

I think you have to disable NetBEUI on the Windows client machine, otherwise it will report "error 733". TCP/IP still works fine, this is just a cosmetic issue. You also need to go into the advanced properties for the vpn on the client and change the TCP/IP settings - go to the WINS tab and put the server address in for WINS server (in this case 192.168.14.100). This allows you to reference remote systems by name instead of IP address.

• This link looks like a great RedHat 8.0 pptpd howto doc.
• Also, add 'ppp' to the pkgSkipList in /etc/sysconfig/rhn/up2date, so up2date won't mess up your ppp.

another troubleshooting tip: I found that on one client, vpn performance was terrible. You could perform actions like make an ssh connection over the vpn, but things like copying files across the vpn would time out. The problem was tcp fragmentation. The default mru (maximum receive unit) on the ppp connection was 1500. For some reason, this was too big for the particular network the vpn was on. The result was massive fragmentation and really, really poor performance. I edited /etc/ppp/options on the pptp server and added the following:

mru 900 mtu 900

and performance immediately improved to the point of usability. I use 900 because it works, Jeff Jones found info indicating 552 might be the right number. Moral of the story: if the vpn works but large file copies stink, drop your mru to avoid fragmentation (if you drop it too far, you won't be able to connect!).