I'm currently running FreeBSD 14.0 Release with MPD 5.9_18.
I'm attempting to use a radius server to auth PAP/CHAP requests.
Here are what I think are the relevant parts of the config:
setlinkactionbundleLTEsetlinkenableincomingsetlinkdisablepeer-as-callingsetlinkenablepapchap
#settingsonthelinksetlinkdisableacfcompsetlinkdisableprotocompsetlinkdisablecheck-magicsetlinkdenyacfcompsetlinkdenyprotocompradiussettings:
setradiusserver172.31.4.193BIYAQsK5BtnM5dUMYt4NYXS53MIlICNA18121813#setradiusserver172.31.4.129BIYAQsK5BtnM5dUMYt4NYXS53MIlICNA18121813setradiusretries2setradiustimeout3
#setradiusenablemessage-authentic#mustberadiusauthsetauthdisableinternalsetauthenableradius-authsetauthenableradius-acct
#setauthenablepapchapsetauthacct-update1605
#don't drop the session if start message isn'trespondedtosetauthdisableacct-mandatory
in the case of CHAP, it appears to just be attempting some sort of local chap auth:
ANd for PAP, one device is able to attach and is handed an IP by radius, while another doesn't appear to be able to.
I'm looking for some help understanding why CHAP isn't handed off to RADIUS correctly.
Previously my company ram a patched version of mpd that had it's own proxy auth, so we're now attempting to upgrade and stick to the default latest version as we no longer need any proxy auth functionality, so I think we migth have some strange config options that aren't helping since we've never ran it with a normal config.
I currently have a cellular test device that I can switch from PAP/CHAP so can test different options.
I've also attached our current full config incase that's useful.
Another thing we see in the RADIUS layer too, is this:
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_ACCT_MULTI_SESSION_ID: 8877876-LTE-2
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_BUNDLE: LTE-2
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_IFACE: ng0
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_IFACE_INDEX: 8
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_MPD_PEER_IDENT:
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_ACCT_LINK_COUNT: 1
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Put RAD_ACCT_AUTHENTIC: 2
Jun 20 10:04:36 manlns1 mpd[95157]: [TUK175193-2] RADIUS: Send request for user ''
Jun 20 10:04:42 manlns1 mpd[95157]: [TUK175193-2] RADIUS: rad_send_request for user '' failed: No valid RADIUS responses received
Which suggests the credentials are blank somehow, but they're definitely set at the device level, and that same device works fine when attaching to our patched 5.8 mpd.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Please do not cut the logs. We need full session log. Also, replace your "log +ALL -EVENTS -FRAME -ECHO +RADIUS +RADIUS2" with something like the following:
So unless the client accepts our use of pap/chap at the lcp layer, then it wont make it to generating a radius request? Or am I misunderstanding?
I think our previous patched version of 5.8 did a sort of proxy auth instead of dealing with it in the lcp error, but it was never merged in to mpd, and is likely uncompatible with the current code base.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Our solution talks to FreeRADIUS also on FreeBSD, so I'd assume it needs CHAP-MD5.
I've tried enabling that too, but no chap setting seems to result in a radius request being generated by MPD, it's like it's just trying to auth locally even though internal auth is disabled.
Thanks
Steven
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm currently running FreeBSD 14.0 Release with MPD 5.9_18.
I'm attempting to use a radius server to auth PAP/CHAP requests.
Here are what I think are the relevant parts of the config:
in the case of CHAP, it appears to just be attempting some sort of local chap auth:
ANd for PAP, one device is able to attach and is handed an IP by radius, while another doesn't appear to be able to.
I'm looking for some help understanding why CHAP isn't handed off to RADIUS correctly.
Previously my company ram a patched version of mpd that had it's own proxy auth, so we're now attempting to upgrade and stick to the default latest version as we no longer need any proxy auth functionality, so I think we migth have some strange config options that aren't helping since we've never ran it with a normal config.
I currently have a cellular test device that I can switch from PAP/CHAP so can test different options.
I've also attached our current full config incase that's useful.
Thanks for any help
The log shows that client was not configured to use MS-CHAPv2 and rejected to used it while mpd5 server was configured to require MS-CHAPv2 (not PAP).
Another thing we see in the RADIUS layer too, is this:
Which suggests the credentials are blank somehow, but they're definitely set at the device level, and that same device works fine when attaching to our patched 5.8 mpd.
Please do not cut the logs. We need full session log. Also, replace your "log +ALL -EVENTS -FRAME -ECHO +RADIUS +RADIUS2" with something like the following:
log +auth +bund +iface +iface2 +ipcp +ipcp2 +link +lcp +lcp2 +rep
Apologies, here are the logs with the recommended log settings:
I've also stripped back our config to be smaller/simpler so there's less chance of something causing an issue. I've attached the new smaller config.
Thanks
Steven
This log indicates exactly same problem: a client rejects to authorize itself with MS-CHAPv2. The client must be reconfigured to use MS-CHAPv2.
Last edit: Eugene Grosbein 2024-06-21
Thanks.
So unless the client accepts our use of pap/chap at the lcp layer, then it wont make it to generating a radius request? Or am I misunderstanding?
I think our previous patched version of 5.8 did a sort of proxy auth instead of dealing with it in the lcp error, but it was never merged in to mpd, and is likely uncompatible with the current code base.
It depends. Do you try to make split LAC/LNS configuration or mpd5 needs to serve users all by itself?
Our solution talks to FreeRADIUS also on FreeBSD, so I'd assume it needs CHAP-MD5.
I've tried enabling that too, but no chap setting seems to result in a radius request being generated by MPD, it's like it's just trying to auth locally even though internal auth is disabled.
Thanks
Steven