Re: poptop on FreeBSD 9.x

There is initial evidence of a converging negotiation, but then one
party keeps repeating the same packet until the negotiation timeout.

The client is rejecting CHAP authentication, and your server is
insisting on it.

> pptpd[1825]: GRE: accepting packet #15
> ppp[1826]: tun0: LCP: deflink: RecvConfigRej(13) state = Ack-Sent
> ppp[1826]: tun0: LCP:  AUTHPROTO[5] 0xc223 (CHAP 0x05)
> ppp[1826]: tun0: LCP: deflink: SendConfigReq(14) state = Ack-Sent
> ppp[1826]: tun0: LCP:  ACFCOMP[2]
> ppp[1826]: tun0: LCP:  PROTOCOMP[2]
> ppp[1826]: tun0: LCP:  ACCMAP[6] 0x00000000
> ppp[1826]: tun0: LCP:  MRU[4] 1500
> ppp[1826]: tun0: LCP:  MAGICNUM[6] 0x1e7efbd1
> ppp[1826]: tun0: LCP:  AUTHPROTO[5] 0xc223 (CHAP 0x05)

According to PPP, upon receipt of a Configuration Reject the local
system must not include the options in any following Configuration
Request.

Yet clearly your system is doing that, for the authentication protocol
option.

I suppose ppp is misconfigured.  I don't know what the configuration
should be, as I have focused on Linux pppd only.  But study the
meaning and effect of each of the options that enable a CHAP.  Should
there be three or one?  If one, which one?  At least one of them isn't
acceptable to the client.

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

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/