Jim Barber wrote:
But then I did something that was strange. I turned on the refuse-chap, refuse-mschap, and require-mschap-v2 options in the options.l2tpd file again, and then tried to connect with VPN client again, expecting it to fail... But it didn't. With the VPN client still configured to only use CHAP, it was allowed to log in despite the 'require-mschap-v2' directive. I had bounced all daemons to make sure that the changes were picked up. Does that give anyone some clues?
Oh, now I know what Tim Warnok suggested earlier. It seems that the ppp options for refusing and requiring certain authentication protocols were being ignored if the l2tpd daemon specified them. From the [lns default] section of the l2tpd.conf file, I need to get rid of the following lines: refuse pap = yes require chap = yes But I still need to keep this line: require authentication = yes After doing that, the options I set in the /etc/ppp/options.l2tpd file now take effect. So I have tested authentication using PAP, and I can allow or deny it as I want.. Likewise with CHAP. But still both the MS-CHAP and the MS-CHAPv2 options won't authenticate against the freeradius server because their challenge and responses aren't getting into the radius Access-Request packet. Frustrating. ---------- Jim Barber DDI Health