Hi Guys,
I would like to share an interesting case that involves L2TP radius authentication. The scenario that one of our customer want to accomplish is to establish and L2TP tunnel from branch to HQ, by authenticating remote side using a radius server. Of course it was not easy from the start :), some problem occur. By doing a packet capture, customer was able to see that the falling point of this issue is the PPP CHAP process, after receiving the Authentication message "ACCEPT" from our radius, the LNS AR2240 send a CHAP failure instantly (no 3-way handshake session involved). To make this info more clear I will insert the topology: 
Certainly it's necesary to start a debugging session while trying to authetication the remote end radius.
On LNS:
debugging ppp all
debugging l2tp all
debugging cm all
debugging radius all
debugging aaa all
I will not post all debugging logs here but I can tell you what messages I was able to spot.
Authentication request
Authentication accept
Attr decode err. (type=11)
Authentication fail with illegal user or password.
LCP opened to closing.
Clearly the most inportand message is the error decode. This tells us that one of the attributes that are send by the radius server cannot be decoded by AR side.
By checking into packet capture we observe some Microsoft private attributes involved into the process. Moreover the "Tunnel-Assignment-Id" attribute have a longer length (15) than the maximum admitted (6). Check the snip.
By removing the Microsoft private attributes and adjusting the lenght for the Tunnel-Assignment-Id attribute we will able to solve the decoding error and advance with the troubleshooting.
It's important to remove unnecessary attributes from the radius messages especially when you work in a multi-vendor environment.
Hope to enjoy reading this case.
