IPCP problem

IPCP problem

[Ionut Turturica]

Hi,

It looks like the pptpd server requests first time mppe-stateful, then it  
changes its mind and wants mppe-stateless. Is there any way to fix this?
(I don't have access to pptpd's config)

[cut]
CHAP authentication succeeded
kernel does not support PPP filtering
sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.19.0.109>]
sent [IPCP TermAck id=0x1]
rcvd [CCP ConfReq id=0x1]
sent [CCP ConfAck id=0x1]
rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D -C>]
sent [CCP ConfReq id=0x2 <mppe -H -M +S -L -D -C>]
rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D -C>]
MPPE 128-bit stateful receive compression enabled
sent [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 0.0.0.0>]
rcvd [IPCP ConfNak id=0x1 <addr 10.20.17.120>]
sent [IPCP ConfReq id=0x2 <compress VJ 0f 01> <addr 10.20.17.120>]
rcvd [IPCP ConfAck id=0x2 <compress VJ 0f 01> <addr 10.20.17.120>]
rcvd [IPCP ConfReq id=0x1 <compress VJ 0f 01> <addr 10.19.0.109>]
sent [IPCP ConfAck id=0x1 <compress VJ 0f 01> <addr 10.19.0.109>]
local  IP address 10.20.17.120
remote IP address 10.19.0.109
Script /etc/ppp/ip-up started (pid 21358)
rcvd [CCP ConfReq id=0x1]
MPPE disabled
Connect time 0.1 minutes.
Sent 0 bytes, received 4 bytes.
sent [LCP TermReq id=0x2 "MPPE disabled"]
sent [CCP ConfReq id=0x3 <mppe +H -M +S -L -D -C>]
sent [CCP ConfAck id=0x1]
Script /etc/ppp/ip-up finished (pid 21358), status = 0x0
Script /etc/ppp/ip-down started (pid 21363)
Script /etc/ppp/ip-down finished (pid 21363), status = 0x0
rcvd [LCP TermAck id=0x2]
Connection terminated.

Re: IPCP problem

[James Carlson]

Ionut Turturica writes:
> It looks like the pptpd server requests first time mppe-stateful, then it  
> changes its mind and wants mppe-stateless. Is there any way to fix this?
> (I don't have access to pptpd's config)

That's not how I read this log.

> sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]

The local system tells its peer that it would like to do 128 bit MPPE
(+S) with stateless mode (+H).

> rcvd [CCP ConfReq id=0x1]

The peer says that it doesn't want to use MPPE or CCP at all.  Are you
sure that you should be using MPPE with this peer?

> sent [CCP ConfAck id=0x1]

The local system agrees to avoid MPPE for the peer!  That looks like a
bug to me.  It's theoretically possible, to encrypt in just one
direction, but it doesn't sound like a good thing.  This should have
been a CCP Configure-Nak instead.

> rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D -C>]

The peer says that it agrees to 128 bit MPPE, but only if stateful
(-H) mode is used.

> sent [CCP ConfReq id=0x2 <mppe -H -M +S -L -D -C>]

We re-request using the peer's options.

> rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D -C>]
> MPPE 128-bit stateful receive compression enabled

MPPE is now up in one direction (data sent from the peer to this
system -- the receive side -- should be encrypted, the other side is
not).

> rcvd [CCP ConfReq id=0x1]
> MPPE disabled

The peer is pretty confused.  It just restarted CCP negotiation for no
apparent reason.  As a result, we've torn down MPPE, as required by
the protocol.

> sent [LCP TermReq id=0x2 "MPPE disabled"]
> sent [CCP ConfReq id=0x3 <mppe +H -M +S -L -D -C>]
> sent [CCP ConfAck id=0x1]

We're apparently trying to restart CCP.

> rcvd [LCP TermAck id=0x2]

The peer loses its mind and shuts down the link.

I'm not sure that the peer agrees that this link should be using MPPE
at all.  Though there's one anomalous thing coming out of pppd, it
seems to me that the real problems here are on the peer's side.

Other than disabling MPPE entirely, I'm not sure what you can do to
fix this.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: IPCP problem

[Ionut Turturica]

Yes, when MPPE is disabled the link comes up but obviously I don't want a  
not encrypted link. The confusing thing is that Windows' native PPTP  
client works just fine, pppd does not. I have no idea what software the  
peer uses and I can't find out, my guess is that it's a M$ Windows.

It would be nice to have some similar logs from windows' client to see how  
does it handle this. There must be a bug in the peer software.

On Sun, 29 Jan 2006 22:20:49 +0200, James Carlson  
<carlsonj@workingcode.com> wrote:

> Ionut Turturica writes:
>> It looks like the pptpd server requests first time mppe-stateful, then  
>> it
>> changes its mind and wants mppe-stateless. Is there any way to fix this?
>> (I don't have access to pptpd's config)
>
> That's not how I read this log.
>
>> sent [CCP ConfReq id=0x1 <mppe +H -M +S -L -D -C>]
>
> The local system tells its peer that it would like to do 128 bit MPPE
> (+S) with stateless mode (+H).
>
>> rcvd [CCP ConfReq id=0x1]
>
> The peer says that it doesn't want to use MPPE or CCP at all.  Are you
> sure that you should be using MPPE with this peer?
>
>> sent [CCP ConfAck id=0x1]
>
> The local system agrees to avoid MPPE for the peer!  That looks like a
> bug to me.  It's theoretically possible, to encrypt in just one
> direction, but it doesn't sound like a good thing.  This should have
> been a CCP Configure-Nak instead.
>
>> rcvd [CCP ConfNak id=0x1 <mppe -H -M +S -L -D -C>]
>
> The peer says that it agrees to 128 bit MPPE, but only if stateful
> (-H) mode is used.
>
>> sent [CCP ConfReq id=0x2 <mppe -H -M +S -L -D -C>]
>
> We re-request using the peer's options.
>
>> rcvd [CCP ConfAck id=0x2 <mppe -H -M +S -L -D -C>]
>> MPPE 128-bit stateful receive compression enabled
>
> MPPE is now up in one direction (data sent from the peer to this
> system -- the receive side -- should be encrypted, the other side is
> not).
>
>> rcvd [CCP ConfReq id=0x1]
>> MPPE disabled
>
> The peer is pretty confused.  It just restarted CCP negotiation for no
> apparent reason.  As a result, we've torn down MPPE, as required by
> the protocol.
>
>> sent [LCP TermReq id=0x2 "MPPE disabled"]
>> sent [CCP ConfReq id=0x3 <mppe +H -M +S -L -D -C>]
>> sent [CCP ConfAck id=0x1]
>
> We're apparently trying to restart CCP.
>
>> rcvd [LCP TermAck id=0x2]
>
> The peer loses its mind and shuts down the link.
>
> I'm not sure that the peer agrees that this link should be using MPPE
> at all.  Though there's one anomalous thing coming out of pppd, it
> seems to me that the real problems here are on the peer's side.
>
> Other than disabling MPPE entirely, I'm not sure what you can do to
> fix this.
>