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:
IOS Local AAA
Next, the syntax for using per-user AAA is relatively straightforward. First, you create an AAA attribute list using the command aaa attribute list:
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
Cryptanalysis of Microsoft’s PPTP Authentication Extensions
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).
IOS Local AAA
Next, the syntax for using per-user AAA is relatively straightforward. First, you create an AAA attribute list using the command aaa attribute list:
aaa attribute list PER_USER attribute type inacl PER_USER_ACL service ppp protocol ip attribute type addr 172.16.31.200 service ppp protocol ipNote 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
Cryptanalysis of Microsoft’s PPTP Authentication Extensions
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).
! ! Enable AAA and configure methods ! aaa new-model aaa authentication ppp default local aaa authorization network default local ! ! Create the AAA attribute list ! no aaa attribute list PER_USER aaa attribute list PER_USER attribute type inacl PER_USER_ACL service ppp protocol ip attribute type addr 172.16.31.200 service ppp protocol ip attribute type interface-config "ip unnumbered Loopback1" service ppp protocol lcp attribute type interface-config "ip vrf forwarding TEST" service ppp protocol lcp attribute type interface-config "rate-limit output 256000 8000 8000 conform-action transmit exceed-action drop" service ppp protocol lcp ! ! Create a user and apply the list ! username TEST password 0 CISCO username TEST aaa attribute list PER_USER ! ! Local address pool for PPTP ! ip local pool PPTP_POOL 172.16.31.100 172.16.31.199 ! ! VRF could be bound to incoming connection ! ip vrf TEST rd 1:1 ! ! PPTP VPDN configs ! vpdn enable ! vpdn-group PPTP ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 2 ! ! A Loopback inside VRF ! interface Loopback1 ip vrf forwarding TEST ip address 172.16.31.254 255.255.255.255 ! ! Virtual-Template, dont forget IP address here. ! interface Virtual-Template2 ip unnumbered gigabitEthernet 0/1.111 ppp authentication pap chap peer default ip address pool PPTP_POOL ! ! The per-user ACL ! ip access-list extended PER_USER_ACL permit ip any 192.168.0.0 0.0.255.255 permit ip any 172.16.0.0 0.15.255.255Now looks at some debugging commands output below:
Router#debug ppp negotiation Router#debug aaa per-user AAA/BIND(00000029): Bind i/f AAA/BIND(00000029): Bind i/f Virtual-Template2 ppp12 PPP: Send Message[Dynamic Bind Response] ppp12 PPP: Using vpn set call direction ppp12 PPP: Treating connection as a callin ppp12 PPP: Session handle[7F00000E] Session id[12] ppp12 PPP: Phase is ESTABLISHING, Passive Open ppp12 LCP: State is Listen ppp12 LCP: I CONFREQ [Listen] id 1 len 21 ppp12 LCP: MRU 1400 (0x01040578) ppp12 LCP: MagicNumber 0x105F3A92 (0x0506105F3A92) ppp12 LCP: PFC (0x0702) ppp12 LCP: ACFC (0x0802) ppp12 LCP: Callback 6 (0x0D0306) ... ppp12 LCP: State is Open ppp12 PPP: Phase is AUTHENTICATING, by this end ppp12 LCP: I IDENTIFY [Open] id 5 len 18 magic 0x105F3A92 MSRASV5.10 ppp12 LCP: I IDENTIFY [Open] id 6 len 31 magic 0x105F3A92 MSRAS-0-XP-OFFICE-VISIO ppp12 PAP: I AUTH-REQ id 11 len 15 from "TEST" ppp12 PAP: Authenticating peer TEST ppp12 PPP: Phase is FORWARDING, Attempting Forward ppp12 PPP: Phase is AUTHENTICATING, Unauthenticated User ppp12 PPP: Phase is FORWARDING, Attempting Forward ppp12 PPP: Send Message[Connect Local] ppp12 PPP: Bind to [Virtual-Access3.1] AAA/BIND(00000029): Bind i/f Virtual-Access3.1 Vi3.1 PPP: Send Message[Static Bind Response] Vi3.1 PPP: Phase is AUTHENTICATING, Authenticated User AAA/AUTHOR (0x29): Pick method list 'default' AAA/AUTHOR (0x29): Pick method list 'default' ! ! Look at the per-user AAA command output: ! Note the attribute names, they match ! the ones we configured. ! Vi3.1 PPP/AAA: Check Attr: Framed-Protocol Vi3.1 PPP/AAA: Check Attr: username Vi3.1 PPP/AAA: Check Attr: inacl: Peruser Vi3.1 PPP/AAA: Check Attr: addr Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 AAA/AUTHOR/FSM: We can start LCP Vi3.1 PPP/AAA: Check Attr: Framed-Protocol Vi3.1 PPP/AAA: Check Attr: username Vi3.1 PPP/AAA: Check Attr: inacl: Peruser Vi3.1 PPP/AAA: Check Attr: addr Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 PPP/AAA: Check Attr: interface-config: Peruser I/F Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: Process Attr: interface-config Vi3.1 AAA/AUTHOR/LCP: IF_config: ip unnumbered Loopback1 ip vrf forwarding TEST rate-limit output 256000 8000 8000 conform-action transmit exceed-action drop ip unnumbered Loopback1 ip vrf forwarding TEST rate-limit output 256000 8000 8000 conform-action transmit exceed-action drop Vi3.1 PAP: O AUTH-ACK id 11 len 5 Vi3.1 PPP: Phase is FORWARDING Vi3.1 PPP: Queue CCP code[1] id[7] Vi3.1 PPP: Phase is UP Vi3.1 AAA/AUTHOR/IPCP: Already authorized Vi3.1 AAA/AUTHOR/FSM: We can start IPCP Vi3.1 IPCP: O CONFREQ [Closed] id 1 len 10 Vi3.1 IPCP: Address 172.16.31.254 (0x0306AC101FFE) Vi3.1 PPP: Process pending ncp packets Vi3.1 CCP: Redirect packet to Vi3.1 Vi3.1 CCP: I CONFREQ [Not negotiated] id 7 len 10 Vi3.1 CCP: MS-PPC supported bits 0x01000001 (0x120601000001) Vi3.1 LCP: O PROTREJ [Open] id 2 len 16 protocol CCP (0x80FD0107000A120601000001) Vi3.1 IPCP: I CONFREQ [REQsent] id 8 len 34 Vi3.1 IPCP: Address 0.0.0.0 (0x030600000000) Vi3.1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Vi3.1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Vi3.1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Vi3.1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) Vi3.1 AAA/AUTHOR/IPCP: Start. Her address 0.0.0.0, we want 0.0.0.0 Vi3.1 AAA/AUTHOR/IPCP: Processing AV inacl Vi3.1 AAA/AUTHOR/IPCP: Processing AV addr Vi3.1 AAA/AUTHOR/IPCP: Processing AV inacl Vi3.1 AAA/AUTHOR/IPCP: Processing AV addr Vi3.1 AAA/AUTHOR/IPCP: Authorization succeeded Vi3.1 AAA/AUTHOR/IPCP: Done. Her address 0.0.0.0, we want 172.16.31.200 Vi3.1 AAA/AUTHOR/IPCP: no author-info for primary dns Vi3.1 AAA/AUTHOR/IPCP: no author-info for primary wins Vi3.1 AAA/AUTHOR/IPCP: no author-info for seconday dns Vi3.1 AAA/AUTHOR/IPCP: no author-info for seconday wins Vi3.1 IPCP: O CONFREJ [REQsent] id 8 len 28 Vi3.1 IPCP: PrimaryDNS 0.0.0.0 (0x810600000000) Vi3.1 IPCP: PrimaryWINS 0.0.0.0 (0x820600000000) Vi3.1 IPCP: SecondaryDNS 0.0.0.0 (0x830600000000) Vi3.1 IPCP: SecondaryWINS 0.0.0.0 (0x840600000000) ! ! Now the router offers the client the static IP ! configured using the “Addr” attribute ! Vi3.1 IPCP: I CONFACK [REQsent] id 1 len 10 Vi3.1 IPCP: Address 172.16.31.254 (0x0306AC101FFE) Vi3.1 IPCP: I CONFREQ [ACKrcvd] id 9 len 10 Vi3.1 IPCP: Address 0.0.0.0 (0x030600000000) Vi3.1 IPCP: O CONFNAK [ACKrcvd] id 9 len 10 Vi3.1 IPCP: Address 172.16.31.200 (0x0306AC101FC8) Vi3.1 IPCP: I CONFREQ [ACKrcvd] id 10 len 10 Vi3.1 IPCP: Address 172.16.31.200 (0x0306AC101FC8) Vi3.1 IPCP: O CONFACK [ACKrcvd] id 10 len 10 Vi3.1 IPCP: Address 172.16.31.200 (0x0306AC101FC8) Vi3.1 IPCP: State is Open AAA/AUTHOR: Processing PerUser AV inacl AAA/AUTHOR: Processing PerUser AV inacl Vi3.1 IPCP: Install route to 172.16.31.200Now look at the virtual cloned interface IP settings:
Router#show ip interface virtual-access 3.1 Virtual-Access3.1 is up, line protocol is up Interface is unnumbered. Using address of Loopback1 (172.16.31.254) Broadcast address is 255.255.255.255 Peer address is 172.16.31.200 ... Inbound access list is PER_USER_ACL, default is not set ... VPN Routing/Forwarding "TEST" Router#sh running-config interface virtual-access 3.1 interface Virtual-Access3.1 ip vrf forwarding TEST ip unnumbered Loopback1 rate-limit output 256000 8000 8000 conform-action transmit exceed-action dropAs 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:
inacl interface-config outacl route rte-fltr-in rte-fltr-out sub-policy-In sub-policy-Out policy-route prefixFor more information on IKE and Locall AAA (and configuration examples) refer to the following link:
0 comments:
Post a Comment