[pptp-server] It works pretty well, but still some sticky pro blems!

George Vieira GeorgeV at citadelcomputer.com.au
Sun Aug 12 07:43:31 CDT 2001


1. Try adding
 
lcp-echo-failure 10
lcp-echo-interval 3
 
to your options.pptp file. this helps detect dead pppd links and drops the
pppd connection if any. Then it's up to the client to reconnect.
 
2. Can't remember the patch but usually in the first line it tells you how
to use it... something line
patch -p1 < patchfile
 
3. The scripts are (usually) called. The problem may be that pppd probably
didn't totally die or something... the fix in problem 1 may also fix this..
Also try using ipparam and linkname in your pppd command line.. then in
ip-down.local use $6 to determine the ipparam used and log the time/date to
help diagnose lose of connectione etc..
 

-----Original Message-----
From: Plastic [mailto:plasticplastic at ameritech.net]
Sent: Sunday, August 12, 2001 5:52 AM
To: pptp-server at lists.schulte.org
Subject: [pptp-server] It works pretty well, but still some sticky problems!


Hi.
 
I've gotten everything working now, except 3-1/2 things:
 
1. The Win 98 VPN client can "dial in" and access the LAN, browse, access
shares. The LAN machines can (finally) browse the incoming machine and
access its shares. However, after the client has been connected for a
certain amount of time, which varies from perhaps 15 minutes to 5 hours, the
connection (at least the tunnel part) goes dead. Pppd, pptpd, and even the
client's VPN adapter do not seem to be aware of this. (Sometimes the client
figures it out a few hours later, tho.) Once this happens, no traffic goes
through the tunnel, not even pinging. I did install the 1.1.2 version of
pptpd, since I saw messages in the archives for this list to the effect that
it might solve this issue, only it has not done so. The next diagnostic I'm
going to try is to have the client connect with no MPPE and see if this
happens, or completely fails to appear, over a full 24 hour period.
 
2. I downloaded the two patches on themm.net to strip off the \\WORKGROUP
from login usernames and to require use of MPPE  eryption,  However I can
find no instructions as to how to properly apply them, which may be why the
patch utility gives a lot of errors when I try to do so. (I am curious as to
why one incoming Win 98 machine always uses the \\WORKGROUP prefix on the
login username and another never does, although they are both set up with
the same workgroup name.)
 
I'm using a ppp-2.3.11.tar.gz which somehow already has all the MPPE 40 and
128, and MSCHAP v1 and v2, stuff already enabled. It's even in the man
pages! I'm using a linux 2.2.16 kernel source. I use a pkg called
ppp-2.3.11-4_MPPE_MSCHAP2.i386.rpm which has a bunch of patches with an
install script that automatically patches the kernel source And amazingly
the kernel and modules all compile fine, with only one manual hack in a line
with a call to the kill_fasynch function, that most of you are probably
familiar with.
 
3. I saw other ppl were having a problem that I had, and still have, with
pppd/ppp, which is that the ip-down script never gets called. Has anyone
found a solution? Even putting an explicit "disconnect script" clause in my
options.pptpd file will not force it to happen.
 
 
I pulled my hair out for 2 days over the issue of making the incoming hosts
visible on the LAN browse list and getting it to share it's own resources.
Even a 2 hour call to Redmond did not help, even though I specifically asked
if the thing that finally was the real problem could be the problem, which
GREATLY delayed resolution,--they said it couldn't be. The solution turned
out to be very simple. At least with Win 98 v.1, you must have NetBT enabled
on not only the VPN  adapter, but also on the ordinary DUN adapter, or else
it refuses to make shares available on even the VPN one. This seems really
illogical (thanks MS!) security-wise especially for anyone using a modem or
"modem-like" situation to connect to the Net and then to the VPN server. It
does not even matter if you are using DUN to connect to the Internet before
"dialing up" with the VPN connectoid or not, because, even if you are
accessing the Net through a gateway on the LAN over Ethernet, just having
NetBT unbound from DUN adapter #1 will break things.
 
I had followed the suggestions in the HowTos and FAQs for PoPToP and was
able to offer a LAN browse list to the VPN client by pointing it at a Samba
WINS service running on the LAN eth0 interface of the machine PoPToP is
running on. Now, I've made the VPN client appear on the LAN browse list,
too, by using the "remote browse sync = " option of Samba, setting it to
"192.168.1.20/32" where 192.168.1.0 is the LAN subnet and 192.168.1.20 is
the IP given to the incoming host. The only issue with this so far is that
once the machine appears in the list, it won't go away, even after the VPN
connection has been disconnected for many hours. I can't make Samba's nmbd
active on both the LAN eth0 interface and the 192.168.1.10 IP that is the
local ppp+ for pptpd, because Samba always figures out it's on the same
subnet as eth0 and won't bind. I can't pre-bind it to ppp+, as Samba doesn't
like that either. And finally, I cannot make the VPN clients appear on
another subnet, because the Samba/PoPToP box is not the LAN's gateway, so
192.168.2.X packets would get sent to the gateway and vanish.
 
 
Thanks,
 
JS
 
 
PS:
 
I hope the Win 98 128-bit update is made available again by MS very soon.
 
 
***No fancy Net Admin tags down here, since I'm just a hobbyist!!***
 
 




More information about the pptp-server mailing list