CHAP problem with PPPoE server
Hi List, I've got a problem which I now know isn't FreeRADIUS misbehaving but seems to be some CHAP-related issue, but I can't see what. With advanced apologies for being somewhat off-topic, I'm wondering if anyone has any ideas? I've been building a test PPPoE server on Linux, specifically CentOS 5.5 with pppd 2.4.4 (also tried 2.4.5) and freeradius-client 1.1.6. PPPoE provided by rp-pppoe-3.10. The server is FreeRADIUS 1.1.7 which I know is a bit old, but this is in use as a production machine and authenticates a lot of PPP and interactive login requests without any trouble so hasn't been upgraded for a while. In my test setup, all attempts to use CHAP or MSCHAP-v2 for authentication fail, basically because there is no CHAP challenge or password sent with the Access-Request. Not unreasonably, the radius server rejects the request: rad_recv: Access-Request packet from host 217.65.165.176:43606, id=160, length=54 Service-Type = Framed-User Framed-Protocol = PPP User-Name = "paultest" NAS-IP-Address = 217.65.165.176 NAS-Port = 0 ... auth: No User-Password or CHAP-Password attribute in the request auth: Failed to validate the user. Login incorrect: [paultest/<no User-Password attribute>] (from client vttest02 port 0) I've also set up a FreeBSD PPPoE server to check that this wasn't a client-side problem; currently I'm using a Mac OS X client but it also fails using Windows or a Cisco client. It works OK with the FreeBSD server - hence the statement about knowing it isn't a FreeRADIUS issue: rad_recv: Access-Request packet from host 217.65.165.171:50582, id=224, length=180 User-Name = "paultest" Service-Type = Framed-User Framed-Protocol = PPP MS-CHAP-Challenge = 0x33323733383637393730323730333033 MS-CHAP2-Response = 0x0100b2a9c9bdfa3458c17851fd4170fb83ad0000000000000000967b707a1f73c2fa39c936a671ed4e01beb4c9744466c88e NAS-IP-Address = 217.65.165.171 NAS-Identifier = "build1" Calling-Station-Id = "7c:6d:62:90:36:55" NAS-Port-Type = Ethernet NAS-Port = 12 ... Login OK: [paultest] (from client vttest01 port 12 cli 7c:6d:62:90:36:55) Clearly the difference is in the challenge - but I'm at a loss to understand why this wouldn't "just work" with RADIUS. The pppd logs suggest that it is using CHAP, but it doesn't think that letting the RADIUS server have the challenge is important... Has anyone had a similar problem or can suggest anything? I've been going around in circles here all day and ended up going nowhere. Many thanks, Paul.
Paul Thornton wrote:
I've got a problem which I now know isn't FreeRADIUS misbehaving but seems to be some CHAP-related issue, but I can't see what. With advanced apologies for being somewhat off-topic, I'm wondering if anyone has any ideas?
It isn't a CHAP issue. Read the debug output. There's no CHAP in the request.
In my test setup, all attempts to use CHAP or MSCHAP-v2 for authentication fail, basically because there is no CHAP challenge or password sent with the Access-Request. Not unreasonably, the radius server rejects the request:
No. The request has no CHAP or MS-CHAP attributes in it. So of *course* authentication fails. You can't authenticate someone if they don't supply authentication credentials.
I've also set up a FreeBSD PPPoE server to check that this wasn't a client-side problem;
It's the fault of the RADIUS client. RADIUS clients decide what goes into a request. If the request is missing something, blame the client.
Has anyone had a similar problem or can suggest anything? I've been going around in circles here all day and ended up going nowhere.
Fix the PPP server so that it works. This isn't a FreeRADIUS problem. Alan DeKok.
Hi Alan Alan DeKok wrote:
It isn't a CHAP issue. Read the debug output. There's no CHAP in the request.
Apologies, perhaps I didn't make it clear in my original mail - I agree with everything you've said - the server is doing exactly as it is told and this isn't a FreeRADIUS problem.
Fix the PPP server so that it works.
This is the part that is the mystery. There seems to be scarce information out there about how pppd functions when using radius as a back end (apart from it should 'just work') - most of the documentation about pppd relates to dial-up as a ppp client or a server without using radius. I thought this list was exactly the sort of place that people who may have come across a similar issue could be found. Sorry for the noise if that isn't the case. Paul.
Paul Thornton wrote:
This is the part that is the mystery. There seems to be scarce information out there about how pppd functions when using radius as a back end (apart from it should 'just work') - most of the documentation about pppd relates to dial-up as a ppp client or a server without using radius.
Well... the PPPd people wrote the RADIUS plugin. They need to make sure it works.
I thought this list was exactly the sort of place that people who may have come across a similar issue could be found. Sorry for the noise if that isn't the case.
Questions are fine, but don't be surprised if the answer is "ask the people who wrote the client software" Alan DeKok.
On 09/03/11 10:03, Paul Thornton wrote:
This is the part that is the mystery. There seems to be scarce information out there about how pppd functions when using radius as a back end (apart from it should 'just work') - most of the documentation about pppd relates to dial-up as a ppp client or a server without using radius.
The pppd radius plugin basically replaces the built-in functions in pppd: check_pap check_chap check_mschap ...with it's own, radius-based versions (not those names - something else). It (like most of pppd) is a horrible bit of code, but it does basically work ;o) You need to configure pppd itself to use "chap". This is independent of any radius config - it'll be something like: /etc/ppp/options.<theconnection>: require-chap refuse-pap refuse-mschap refuse-mschap-v2 ...or those same options on the pppd command line, or however your PPPoE daemon takes them.
participants (3)
-
Alan DeKok -
Paul Thornton -
Phil Mayers