[pptp-server] Errors 650 629 645

[John Sutton]

David

At 22:14 06/06/99 +0800, you wrote:
>I think you have a pppd problem rather than a PoPToP problem.
>
>What is the client?  What is your pppd config file like?

Client?  Win95 DUN1.3?  My pppd config file on the linux server is:

asyncmap 0
local
lock
mru 552  (I've varied these between 296 and 1500)
mtu 552
proxyarp
debug
kdebug 1
auth
require-chap
name masq


>My Win98 LAN clients work from a clean boot with no problem.  Ditto Win95
>(with DUN update 1.3 + sockets fix, etc).  Trying it from a dialup here

Eek!  What is "sockets fix"?

>would be.. interesting.. since the same IP address is allocated to dialup
>connections as to PPTP connections for a given username (and all my test
>accounts are dialed up or connected testing things anyway...).
>
>Probably insignificant, but what MTU is your dialup connection using?
>More significantly, are you aware of any firewalling between where you dial
>up to and the VPN server?

What I've done now is gone back to the linux-pptp client (v1.0.2) to try and get a handle on this problem.  And in fact this suffers from exactly the same problem as the Win95 client when used over the dialup connection.  And both wotk fine over the LAN connection.  So I think that rules out it being a Microsoft "feature"... (phew).  So I'm now using the same linux client pppd to establish a dialup connection and to do the pptp client connection.  And the former is solid as a rock.

You suggest it is either a firewall issue or a pppd issue.  Re firewall, yes, there is a masquerading router between the linux server and the internet.  This is configured to forward any unmatched incoming connections to the linux box.  And this works fine for ssh, ftp etc.  If I do a netstat on the linux box when a LAN pptp session is in progress, I get:

tcp        0      0 192.168.1.5:1723        192.168.1.1:1050        ESTABLISHED

So pptp is a simple single socket protocol, yes?  So I can't see why it should not be treated like any other such protocol?  And the fact that this socket does get established when using a dialup connection, at least temporarily, surely indicates that this is not the source of the problem?  Here is a trace on the server:

Sun Jun  6 21:58:47 BST 1999
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      1 192.168.2.2:1723        212.38.64.125:1077      SYN_RECV

Sun Jun  6 21:58:47 BST 1999
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.2.2:1723        212.38.64.125:1077      ESTABLISHED

Stays up for a couple of secs...

Sun Jun  6 21:58:49 BST 1999
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      1 192.168.2.2:1723        212.38.64.125:1077      FIN_WAIT1

Sun Jun  6 21:58:49 BST 1999
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 192.168.2.2:1723        212.38.64.125:1077      FIN_WAIT2

which corresponds to:

Jun  6 21:58:47 masq PPTPD [14430]: starting PPTPCTRL to handle client

...2 secs...

Jun  6 21:58:49 masq PPTPD [14430]: CTRL: this session finished...


Re pppd, I have done extensive testing changing the MTU of the dialup connection and the MTU of the pppd-in-pptp connection.  I found all this extremely difficult because even though I am running everything as root (on both server and client ends), it seems to me that you cannot override some of the settings in /etc/ppp/options either on the command line or in a "file /blah/blah" option?  This has been driving me nuts!  On the client end, I have to establish the dialup connection using my chosen options in /etc/ppp/otions, and then ovewrite this file with the client options I want before kicking off the pptp client...  Have I missed something here?

Anyway, the upshot is this.  The best I have got is where the server sends an LCP request, the client receives it and sends the ACK, and the client also sends its own request.  This happens 10 times.   However, never but never, have I managed to get the server to receive anything from the client...  and sometimes the server does not even send a request because the connection has already terminated.

Any ideas...  This is so damn close I could scream.  Indeed, I've done quite a bit of that today!

Regards
John

***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 621021
***************************************************