Re: [pptp-devel] PPTP client config problem

[James C. <qu...@la...>]

On Mon, Sep 05, 2011 at 02:21:32PM +0300, Boris Borisov wrote:
> ??  5.09.2011 01:44, James Cameron ??????:
> > On Sun, Sep 04, 2011 at 12:21:27AM +0300, Boris Borisov wrote:
> >> Under windows from same machine I not have problem - that means reasone
> >> for failure are not NAT.
> > Not necessarily.  We have heard of NAT implementations that inspect the
> > PPTP packets and only work with Windows.
> >
> > I'm not sure I understand what you are doing, but if it involves
> > multiple tunnel clients behind a NAT connected to the same tunnel
> > server, you are stretching the NAT implementation considerably.
> >
> > Try the same thing with the clients directly connected to the server,
> > and you might not have a problem.
> >
> > Try OpenVPN, it requires less NAT packet inspection.
> >
> I not able to run OpenVPN because not have access to the server only
> sysadm can provide this service, but he not want to support me (because
> all working under windows, the mistake are my).

It's not that simple.  Because of stateful inspection by NAT routers,
sometimes Linux packets cannot get through, but Windows packets can.  We
have seen that before on this mailing list.

> I try to explain whath is happen (only under linux):
> 1. Case 1:
> Run pptp client when I send LCP request the server are not answer. I
> receive initial state answers and final hangup answer but not receive LCP

That means the NAT router is dropping the packets.  Can you replace the
NAT router or try a different service provider?

> 2. Case 2:
> Run pptp client during send LCP request (no answer from server) I start
> again the same pptp connection. In this case I establish connection and
> have access to VPN but only for 1 minute. When the first (unsuccessful)
> pptp process are finish then this (first process) shutdown the ppp
> interface.

Two streams originating from the same IP is sometimes not handled
correctly.

You might instead run one client, and use that client as a router to the
tunnel network.

> Possible solution:
> 1. To find root cause - I not found because i'm not expert in packet and
> handshaking algo of pptp, but can provide tcpdump of firs 16-18 packet
> under linux and under windows.

If you did provide that, I would likely prove to you that the router is
the cause.

-- 
James Cameron
http://quozl.linux.org.au/