# cat pptpd.conf

option /etc/ppp/options.pptpd
logwtmp
bcrelay eth0
localip 192.168.1.200
remoteip 192.168.1.201-250

{{{ Wait a tick... Is that suppose to say 192.168.1.150 instead of .200? }}}

# cat options.pptpd

lock
debug
noauth
name joshua
nobsdcomp
proxyarp
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe
nomppe-stateful
ms-dns 68.94.156.1
defaultroute

Open to options...

Quote: {{{ Wait a tick... Is that suppose to say 192.168.1.150 instead of .200? }}}

Guess not. Didn't make any difference...

As I'm sure you realise it's
LCP: timeout sending Config-Requests
that's the problem at the moment. I've got to split this post as I need to have made 5 before I can post external links .....

Check out http://pptpclient.sourceforge.net/ho...is.phtml#debug

to see if you can turn up the volume on the debug output. There's loads of other stuff on here too - see particularly the section http://pptpclient.sourceforge.net/ho...ml#lcp_timeout

but I'd start with the debug output first.

You do realize I'm setting up a server, right? These links are for pptpclient...

Restarted the pptpd service again to try something... Changed 'debug' to 'debug dump' in my options.pptpd file...

What the...?

# tail /var/log/messages

pptpd: pptpd shutdown succeeded
bcrelay[21312]: Running as child
pptpd[21311]: MGR: Manager process started
pptpd[21311]: MGR: Maximum of 50 connections available
pptpd: pptpd startup succeeded
pptpd[21315]: CTRL: Client 71.14.72.115 control connection started
pptpd[21315]: CTRL: Starting call (launching pppd, opening GRE)
pppd[21316]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
pppd[21316]: pptpd-logwtmp: $Version$
pppd[21316]: pppd options in effect:
pppd[21316]: debug^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: dump^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: plugin /usr/lib/pptpd/pptpd-logwtmp.so^I^I# (from command line)
pppd[21316]: require-mschap-v2^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: refuse-pap^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: refuse-chap^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: refuse-mschap^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: name joshua^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: pptpd-original-ip 71.14.72.115^I^I# (from command line)
pppd[21316]: 115200^I^I# (from command line)
pppd[21316]: lock^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: local^I^I# (from command line)
pppd[21316]: ipcp-accept-local^I^I# (from /etc/ppp/options)
pppd[21316]: ipcp-accept-remote^I^I# (from /etc/ppp/options)
pppd[21316]: ipparam 71.14.72.115^I^I# (from command line)
pppd[21316]: ms-dns xxx # [don't know how to print value]^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: defaultroute^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: proxyarp^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: 192.168.1.150:192.168.1.201^I^I# (from command line)
pppd[21316]: nobsdcomp^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: require-mppe^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: nomppe-stateful^I^I# (from /etc/ppp/options.pptpd)
pppd[21316]: pppd 2.4.3 started by root, uid 0
pppd[21316]: Using interface ppp0
pppd[21316]: Connect: ppp0 <--> /dev/pts/131
pptpd[21315]: GRE: Bad checksum from pppd.
pptpd[21315]: CTRL: Ignored a SET LINK INFO packet with real ACCMs!
pppd[21316]: MPPE 128-bit stateless compression enabled
pppd[21316]: not replacing existing default route to eth0 [192.168.1.1]
pppd[21316]: found interface eth0 for proxy arp
pppd[21316]: local IP address 192.168.1.150
pppd[21316]: remote IP address 192.168.1.201
pppd[21316]: pptpd-logwtmp.so ip-up ppp0 hackman 71.14.72.115

HALLELUIA! I'M IN!! -- I can see the SAMBA server and I can map the share!!!

Okay, now let's see if I can repeat this...

Excellent! It's possible the previous failure was due to one of the routers or the server not clearing the previous (non)connection properly. I have definitely had this where I break a connection, have a "b!ggarit, forgot something" moment and try to reconnect and can't for a few minutes.

Sorry, I didn't notice the link was for the client. In my defence I have used that page to troubleshoot from as a lot of the problems addressed are symmetrical between client and server.

Hmm... Only one problem... And you're right, it's a routing problem... It will let me all over the local network, pinging LAN workstations, the server and such, but won't let me out to the internet. Gives a gateway of 192.168.1.201, which is the network IP it gives itself... Eh?

Strangely, Tim, the extra 'dump' after 'debug' seemed to make a difference... Don't ask me! The logs speak for themselves...

I guess I should have added a route to 192.168.1.1 from the 192.168.1.200-254

How do I do that? Do I go into 'pptp setup' and rebuild the tunnel with a route?

If so, when it says 'route:' what do I put?

Simple solution: On the XP client, go into Properties (on the network connection)->Networking Tab->Internet Protocol(TCP/IP) Properties->Advanced and untick the "Use default gateway on remote network" and OK, Ok and OK. That way, client internet traffic won't get routed down the VPN.

I think that worked...

Okay, cool!

One final thing you might want to look at is the PPTP-Server module for Webmin - big help for administration.

Yeah, but being remote through this SSH connection doesn't allow such niceties. I did download it, but probably won't impliment it until I show up at the office next time. At least now I won't get jeered!

Thanks so much for all your help and have a Merry Christmas!

Just sent the XP docs to the onsite 'power user' she's gonna try them out. Found out one of my remotes "might be a Win98 user." Sent the link for the DUN 1.4 upgrades and told them to either install them at their own risk or go buy the XP upgrade.

*SIGH* I feel like I just gave birth!