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