IOS Local AAA is one feature that is often overlooked for some reason. It allows turning your router into almost full-functional AAA server, allowing not only local authentication of remote VPN users but also local authorization for protocols like PPP (used with PPTP/PPPoE or dialup) or IKE (used with ezVPN). Best of all, you can use per-user attribute lists with PPP (alas, it does not seem to work with IKE). With per-user attribute-lists you can apply specific configuration policy with maximum granularity. First, here is the link from Cisco's documentation site, just for your information:

Note that you must correctly specify service (e.g. PPP or IKE) and protocol (e.g. LCP or IP) in order for attributes to apply correctly. For example, if you specify “inacl” attribute with protocol LCP it won’t work, as the IP access-list is applied at the IPCP stage. To get the list of all IOS supported attributes, you can use the context-sensitive help under “aaa attribute list” configuration mode. You can also use the command show aaa attributes for the list of all IOS AAA attributes and their format. Lastly, if you want to map RADIUS IETF attribute names/numbers to the names used by IOS, use the command show aaa attributes protocol radius.

And now, look at the following example. We are using the all-popular PPTP here, as it’s available in almost every Windows/Mac machine in the world. While PPTP is not the best tunneling protocol in the world (thanks to it’s separate TCP control channel and not-very-NAT-friendly GRE tunnel) it’s very flexible thanks to underlying PPP. Still, the same PPP limits the security of PPTP due to MPPE (MS Point-to-Point encryption) protocol, which has been criticized for some potential flaws related to PPP authentication protocols and cipher key generation. Though the migration to MS-CHAPv2 greatly reduces many security risks, it’s still not as secure as IPsec tunnels. You can read more at

In the following example, we configured PPP for local authentication and using local database to authorize network attributes. There is an attribute list, which is later assigned to a user. This list instructs the router to apply an inbound access-list (the list should be locally configured in the router) plus assign the interface into specific VRF, using the interface level commands. Additionally, we assign a fixed IP address to the user – an operation which is quite commonly required. The final attribute applies a rate-limit command to the interface, just to illustrate some simple QoS configuration. Note that you can also use “sub-policy-Out” and “sub-policy-In” to apply a policy-map to the cloned interface. Finally we set up PPTP in a “quick-and-dirty” manner and then test our configuration. You can configure any Windows host to connect to your VPN server using PPTP and CHAP authentication (no encryption).

As you can see, all the configured attributes have been applied. Note, that the rich set of attributes is applicable particularly to PPP. If you are using say ezVPN Virtual-Tunnel-Interface, you are restricted only to the following attributes: