Oct
07

Another new update is now available for the CCIE Security Advanced Technologies Class. This update adds an additional 15 hours of videos to the series, which includes the rest of IPsec, IPS, and AAA. All Access Pass subscribers and customers who purchased download access can login to the INE members site to see the new additions.  This brings the series up to about 40 hours of videos, which will be further increased with some minor updates I'll be adding over the next few weeks. If there is a specific topic which is missing that you'd like to see feel free to comment here, or email me at bmcgahan@ine.com.

The outline for the series is now as follows:

  • Introduction - 0h 37m
  • CCIE Security Preparation Resources - 0h 50m
  • ASA Overview - 0h 37m
  • Basic ASA Initialization - 1h 02m
  • ASA Routing - 0h 37m
  • ASA Reliable Static Routing - 0h 20m
  • ASA Access Control Lists (ACLs) - 0h 41m
  • ASA Modular Policy Framework (MPF) Overview - 0h 53m
  • ASA Modular Policy Framework (MPF) Configuration - 0h 51m
  • ASA Advanced TCP Inspection with MPF - 0h 40m
  • ASA Advanced Application Inspection with MPF - 0h 36m
  • ASA Quality of Service (QoS) - 0h 30m
  • ASA Network Address Translation (NAT) Part 1 - 0h 50m
  • ASA Network Address Translation (NAT) Part 2 - 0h 30m
  • ASA Transparent Firewall Overview - 0h 25m
  • ASA Transparent Firewall Configuration - 0h 43m
  • ASA ARP Inspection with Transparent Firewall - 0h 21m
  • ASA Multiple Context Mode Overview - 0h 42m
  • ASA Multiple Context Mode Configuration - 0h 59m
  • ASA Redundant Interfaces - 0h 22m
  • ASA Failover Overview - 0h 19m
  • ASA Active/Standby Failover Routed Firewall Configuration - 0h 29m
  • ASA Active/Standby Failover Transparent Firewall Configuration - 0h 17m
  • ASA Active/Active Failover Routed Firewall Configuration - 0h 37m
  • ASA Multiple Context Transparent Firewall Configuration - 0h 29m
  • ASA Active/Active Failover Transparent Firewall Configuration - 0h 29m
  • IOS Access Control Lists (ACLs) - 0h 23m
  • IOS Time Based ACLs - 0h 13m
  • IOS Lock & Key Security with Dynamic ACLs - 0h 24m
  • IOS Reflexive ACLs - 0h 44m
  • IOS TCP Intercept and Content Based Access Control (CBAC) - 0h 39m
  • Zone Based Policy Firewall Overview - 0h 26m
  • Zone Based Policy Firewall Configuration - 0h 44m
  • ZBPF Self Zone & ZBPF Exceptions - 0h 48m
  • Port to Application Mapping (PAM) - 0h 32m
  • ZBPF Parameter Tuning - 0h 32m
  • ZBPF Application Inspection - 0h 27m
  • IOS Transparent Firewall - 0h 28m
  • IPsec Overview - 0h 37m
  • IOS IPsec LAN-to-LAN Configuration - 0h 58m
  • IPsec Troubleshooting - 0h 42m
  • GRE over IPsec, IPsec Profiles, & VTIs - 0h 51m
  • ASA IPsec Overview - 0h 24m
  • ASA IPsec LAN-to-LAN Configuration - 0h 20m
  • Certificate Authority (CA) Overview - 0h 16m
  • IOS & ASA LAN-to-LAN IPsec with Certificates - 0h 57m
  • Easy VPN Overview - 0h 12m
  • IOS Easy VPN Server - 1h 10m
  • IOS Easy VPN Client - 0h 30m
  • IOS Easy VPN with Dynamic VTIs, ISAKMP Profiles - 0h 49m
  • ASA Easy VPN Server - 0h 51m
  • ASA Easy VPN Server & IOS Easy VPN Client - 0h 17m
  • ASA Clientless & AnyConnect SSL VPN - 1h 04m
  • DMVPN - 1h 05m
  • IPS Overview, Promiscuous Mode & SPAN - 0h 43m
  • IPS Promiscuous Mode & RSPAN - 0h 28m
  • IPS Blocking Devices & Custom Signatures - 0h 50m
  • IPS Inline Mode, VLAN Pairing - 0h 15m
  • IPS Virtual Sensors and Signature Engines - 0h 16m
  • AAA Overview, Local AAA, & Role Based CLI - 0h 51m
  • RADIUS, TACACS+, & Cisco Secure ACS Configuration - 0h 51m
  • RADIUS & TACACS+ Exec Authorization & Accounting - 0h 39m
  • TACACS+ Command Accounting - 0h 30m
  • RADIUS & TACACS+ Enable Authentication - 0h 14m
  • IOS Authentication Proxy - 0h 33m
May
18

In this blog post we are going to review and compare the ways in which IOS and ASA Easy VPN servers perform ezVPN attribute authorization via RADIUS. The information on these procedure is scattered among the documentation and technology examples, so I thought it would be helpful to put the things together.

To begin with, let’s establish some sort of equivalence between the IOS and ASA terminology. Even though ASA inherited most of it’s VPN configuration concepts from the VPN3000 platform it is still possible to find similarities between the IOS and the ASA configurations. Recall that IOS ezVPN configuration defines local ezVPN group policy by means of the crypto isakmp client configuration group command. This could be viewed as a rough equivalent to the ASA’s group-policy type internal command, though the ASA’s command scope is much broader. IOS ISAKMP profiles could be viewed as an equivalent to the ASA’s tunnel-group command defining a connection profile.

”Landing” an Incoming Connection

Both IOS and ASA platforms attempt to match an incoming IPSec connection against ISAKMP profile/tunnel-groups (we do not consider the “legacy” IOS scenarios without ISAKMP profiles defined) defined in the system. You may find the description of the procedure used by the ASA firewalls here Understanding how ASA Firewall Matching tunnel-group Names . IOS router use similar procedure, which is somewhat simplified when using just ezVPN clients. As you know, a typical ezVPN client will either

a) Use IKE Aggressive Mode with ID_KEY_ID identity type, which specifies the ezVPN group name
b) Or use IKE Main Mode with digital certificates and ID_DER_ASN1_DN identity type, which specifies the user’s Distinguished Name.

In the first case, the IOS router will match the group name against the match identity statements of the ISAKMP profiles configured in the system and associate the connection with the configuration group specified by client configuration group. In the second case, either group name is derived from the OU field of the subject’s DN or certificate maps are used to map the names in the certificate to an ISAKMP profile. Additionally, you may use certificate maps associated with ISAKMP profiles by means of the command match certificate to map the incoming identity to an ISAKMP profile.

Enabling External Authorization

In IOS, you define ISAKMP authorization type by assigning an appropriate AAA authorization list to the group using the command isakmp authorization list. In the ASA, if you want the group to be authorized externally, you need to define the group-policy as external, associating it with an AAA server group and assigning a password, e.g. group-policy EZVPN_GROUP external server-group RADIUS password CISCO. The IOS routers allow you to pull the group pre-shared key from the RADIUS server when the client uses PSK authentication. This is not possible with the ASA firewall, as the key is statically defined under the respective tunnel-group. In addition to external group authorization, both IOS and ASA firewall may enable external Xauth authentication/authorization. In the IOS router, this is done by using the ISAKMP profile command client authentication list referencing the AAA list that points to an AAA server. In the ASA firewall you enable external Xauth authentication by means of the tunnel-group ipsec-attributes command authentication-server-group referencing to the AAA server group linked to an external server. In is important to notice that both group authorization and Xauth authentication may pull down groups of RADIUS attributes from the AAA server. The attributes are then merged and conflicts resolved to form the final authorization set.

RADIUS Authorization with IOS

Here is a step-by-step description of the RADIUS authorization process in the IOS routers. Firs of all, notice that the group profile stored in the RADIUS server is a regular user with the name matching the ezVPN group name and the password value of “cisco”. All the policy attributes are stored as Cisco AV pairs associated with the user.

Step 1:
This step is needed for pre-shared keys authentication. The router extracts the group name from IKE message. This could be simply a group name (ID_KEY_ID) or the OU field value from a digital certificate. Using this name and the password value of “cisco” the router authenticates with the RADIUS server and pulls down a number of attributes. The most important attribute is the pre-shared key used by the router to authentication the remote peer. Naturally, digital signatures authentication process does not use this value. The profile stored in the RADIUS server should define at the very least the following IETF RADIUS attributes:

Service-Type=”Outbound” to define the type of service.
Tunnel-Type=”IP ESP” to define the IPSec tunnel.
Tunnel-Password=” ” defines the pre-shared key for the group, if PSK authentication is used. You don’t need this attribute for digital signatures authentication.

In addition to the above IETF RADIUS attributes, the following two Cisco AV-Pairs must be defined for the group:

ipsec:tunnel-type=ESP
ipsec:key-exchange=IKE

All other optional ezVPN attribute are defined by means of Cisco AV-Pair using the syntax “ipsec: ”, for example “ipsec:addr-pool=ADDRESS_POOL”, “ipsec:default-domain=INE.com” and so on. This is in contrary with the ASA firewall, which uses specific RADIUS attributes (Altiga set).

Step 2:
If the respective option is configured under ISAKMP profile, the router starts Xauth for the remote user. If the user should be authenticated against the RADIUS server, the router will use the name and password provided for authentication. As a result, the RADIUS server will return a number of attributes associated with the user. At this step the router compares the av-pair ipsec:user-vpn-group attribute value (if present) with the IKE group name and aborts the connection if they don’t match. This is the newer implementation of the well-known Group Lock feature.

Step 3:
The router once again authenticates with the RADIUS server using the group name and the password value of “cisco”. This is needed as the attributes learned on Step 1 may have been lost during the previous steps, and we need them now to authorize ISAKMP configuration mode requests. The router combines all attributes learned from the RADIUS server in the following order of preference:

a) User attributes
b) Group attributes

That is, any attribute missing from User attributes is filled with Group attributes, and the user attributes override the group attributes

To summarize: IOS router downloads the group policy from the AAA server using the group name and the password of “cisco”. The profile is retrieved to perform group authentication process as to perform group authorization. All policy settings are stored using Cisco AV-Pairs “ipsec:*”.

Debugging Output for IOS RADIUS Policy Download

The following is the output of the command debug crypto isakmp for the remote ezVPN client connecting to an IOS router configured for RADIUS authorization. The process starts with the remote client (IP 136.1.100.200) starting IKE AM exchange with the server.

ISAKMP (0:0): received packet from 136.1.100.200 dport 500 sport 1419 Global (N) NEW SA
ISAKMP: Created a peer struct for 136.1.100.200, peer port 1419
ISAKMP: New peer created peer = 0x83F035D4 peer_handle = 0x8000000B
ISAKMP: Locking peer struct 0x83F035D4, refcount 1 for crypto_isakmp_process_block
ISAKMP: local port 500, remote port 1419
insert sa successfully sa = 82F100E8
ISAKMP:(0): processing SA payload. message ID = 0
ISAKMP:(0): processing ID payload. message ID = 0
ISAKMP (0:0): ID payload
next-payload : 13
type : 11
group id : EZVPN
protocol : 17
port : 500
length : 13

The peer advertises group name EZVPN as it’s ID. The router find a matching ezVPN profile for this connection.

ISAKMP:(0):: peer matches EZVPN profile
ISAKMP:(0):Setting client config settings 83C36734
ISAKMP:(0):(Re)Setting client xauth list and state
ISAKMP/xauth: initializing AAA request
AAA/BIND(00000015): Bind i/f
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 215 mismatch
ISAKMP:(0): vendor ID is XAUTH
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is DPD
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): processing IKE frag vendor id payload
ISAKMP:(0): Support for IKE Fragmentation not enabled
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID seems Unity/DPD but major 123 mismatch
ISAKMP:(0): vendor ID is NAT-T v2
ISAKMP:(0): processing vendor id payload
ISAKMP:(0): vendor ID is Unity
ISAKMP:(0): Authentication by xauth preshared
ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy
ISAKMP: encryption AES-CBC
ISAKMP: hash SHA
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP: keylength of 256
...
ISAKMP:(0):Checking ISAKMP transform 10 against priority 10 policy
ISAKMP: encryption 3DES-CBC
ISAKMP: hash MD5
ISAKMP: default group 2
ISAKMP: auth XAUTHInitPreShared
ISAKMP: life type in seconds
ISAKMP: life duration (VPI) of 0x0 0x20 0xC4 0x9B
ISAKMP:(0):atts are acceptable. Next payload is 3
ISAKMP:(0):Acceptable atts:actual life: 86400
ISAKMP:(0):Acceptable atts:life: 0
ISAKMP:(0):Fill atts in sa vpi_length:4
ISAKMP:(0):Fill atts in sa life_in_seconds:2147483
ISAKMP:(0):Returning Actual lifetime: 86400
ISAKMP:(0)::Started lifetime timer: 86400.

SA policy has been selected, performing DH key-exchange now. At this moment the router attempts to pull down the group attributes to perform peer authentication, using the pre-shared key stored in the RADIUS database. Notice the username used for authentication – it matches the group name.

ISAKMP:(0): processing KE payload. message ID = 0
ISAKMP:(0): processing NONCE payload. message ID = 0
ISAKMP:(0): vendor ID is NAT-T v2
AAA/AUTHOR (0x15): Pick method list 'AUTHOR_RADIUS'
ISAKMP:(0):Input = IKE_MESG_FROM_PEER, IKE_AM_EXCH
ISAKMP:(0):Old State = IKE_READY New State = IKE_R_AM_AAA_AWAIT

RADIUS/ENCODE(0000002F):Orig. component type = VPN_IPSEC
RADIUS: AAA Unsupported Attr: interface [174] 11
RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100]
RADIUS(0000002F): Config NAS IP: 150.1.3.3
RADIUS/ENCODE(0000002F): acct_session_id: 45
RADIUS(0000002F): sending
RADIUS(0000002F): Send Access-Request to 10.0.0.100:1645 id 1645/50, len 97
RADIUS: authenticator 58 56 FD AE 5B DF 91 24 - 9D C5 51 CC 7B F0 60 05
RADIUS: User-Name [1] 7 "EZVPN"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 15 "136.1.100.200"
RADIUS: NAS-Port-Type [61] 6 Virtual [5]
RADIUS: NAS-Port [5] 6 0
RADIUS: NAS-Port-Id [87] 13 "136.1.100.3"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: NAS-IP-Address [4] 6 150.1.3.3

The server returns ACCESS-ACCEPT message along with the authorization attributes. Notice the AV pair values.

RADIUS: Received from id 1645/50 10.0.0.100:1645, Access-Accept, len 145
RADIUS: authenticator 29 27 57 5D AF 05 4A C2 - B4 DE F0 05 4A 78 52 51
RADIUS: Vendor, Cisco [26] 29
RADIUS: Cisco AVpair [1] 23 "ipsec:addr-pool=EZVPN"
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "ipsec:inacl=SPLIT_TUNNEL"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: Tunnel-Type [64] 6 01:ESP [9]
RADIUS: Tunnel-Password [69] 21 01:*
RADIUS: Framed-IP-Address [8] 6 255.255.255.255
RADIUS: Class [25] 25
RADIUS: 43 41 43 53 3A 30 2F 31 38 37 35 65 2F 39 36 30 [CACS:0/1875e/960]
RADIUS: 31 30 33 30 33 2F 30 [10303/0]
RADIUS(0000002F): Received from id 1645/50
ISAKMP:(1023): constructed NAT-T vendor-02 ID

The server finally authenticates the group and sends a response packet.

ISAKMP:(1023):SA is doing pre-shared key authentication plus XAUTH using id type ID_IPV4_ADDR
ISAKMP (0:1023): ID payload
next-payload : 10
type : 1
address : 136.1.100.3
protocol : 0
port : 0
length : 12
ISAKMP:(1023):Total payload length: 12
ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) AG_INIT_EXCH
ISAKMP:(1023):Sending an IKE IPv4 Packet.
ISAKMP:(1023):Input = IKE_MESG_FROM_AAA, PRESHARED_KEY_REPLY
ISAKMP:(1023):Old State = IKE_R_AM_AAA_AWAIT New State = IKE_R_AM2

Now the server requests Xuath credentials from the remote peer.

ISAKMP:(1023):Need XAUTH
ISAKMP: set new node 1195294443 to CONF_XAUTH
ISAKMP/xauth: request attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: request attribute XAUTH_USER_PASSWORD_V2

ISAKMP:(1023): initiating peer config to 136.1.100.200. ID = 1195294443
ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) CONF_XAUTH
ISAKMP:(1023):Sending an IKE IPv4 Packet.
ISAKMP:(1023):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1023):Old State = IKE_P1_COMPLETE New State = IKE_XAUTH_REQ_SENT

ISAKMP (0:1023): received packet from 136.1.100.200 dport 500 sport 1604 Global (R) CONF_XAUTH
ISAKMP:(1023):processing transaction payload from 136.1.100.200. message ID = 1195294443
ISAKMP: Config payload REPLY
ISAKMP/xauth: reply attribute XAUTH_USER_NAME_V2
ISAKMP/xauth: reply attribute XAUTH_USER_PASSWORD_V2

The credentials are sent to the RADIUS server for authentication.

AAA/AUTHEN/LOGIN (00000030): Pick method list 'AUTH_RADIUS'
ISAKMP:(1023):deleting node 1195294443 error FALSE reason "Done with xauth request/reply exchange"
ISAKMP:(1023):Input = IKE_MESG_FROM_PEER, IKE_CFG_REPLY
ISAKMP:(1023):Old State = IKE_XAUTH_REQ_SENT New State = IKE_XAUTH_AAA_CONT_LOGIN_AWAIT

RADIUS/ENCODE(00000030):Orig. component type = VPN_IPSEC
RADIUS: AAA Unsupported Attr: interface [174] 11
RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100]
RADIUS/ENCODE(00000030): dropping service type, "radius-server attribute 6 on-for-login-auth" is off
RADIUS(00000030): Config NAS IP: 150.1.3.3
RADIUS/ENCODE(00000030): acct_session_id: 46
RADIUS(00000030): sending
RADIUS(00000030): Send Access-Request to 10.0.0.100:1645 id 1645/51, len 91
RADIUS: authenticator 45 51 AD B1 9F 57 60 0E - 6D 75 24 37 CD 23 DC 9D
RADIUS: User-Name [1] 7 "CISCO"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 15 "136.1.100.200"
RADIUS: NAS-Port-Type [61] 6 Virtual [5]
RADIUS: NAS-Port [5] 6 0
RADIUS: NAS-Port-Id [87] 13 "136.1.100.3"
RADIUS: NAS-IP-Address [4] 6 150.1.3.3

The response contains the user-vpn-group attribute value of “EZVPN”.

RADIUS: Received from id 1645/51 10.0.0.100:1645, Access-Accept, len 85
RADIUS: authenticator 48 5E 75 29 58 1D DC 53 - 42 FB 1F 5C 35 12 24 22
RADIUS: Framed-IP-Address [8] 6 255.255.255.255
RADIUS: Vendor, Cisco [26] 34
RADIUS: Cisco AVpair [1] 28 "ipsec:user-vpn-group=EZVPN"
RADIUS: Class [25] 25
RADIUS: 43 41 43 53 3A 30 2F 31 38 37 35 66 2F 39 36 30 [CACS:0/1875f/960]
RADIUS: 31 30 33 30 33 2F 30 [10303/0]
RADIUS(00000030): Received from id 1645/51
ISAKMP: set new node 1673765102 to CONF_XAUTH
ISAKMP:(1023): initiating peer config to 136.1.100.200. ID = 1673765102
ISAKMP:(1023): sending packet to 136.1.100.200 my_port 500 peer_port 1604 (R) CONF_XAUTH
ISAKMP:(1023):Sending an IKE IPv4 Packet.
ISAKMP:(1023):Input = IKE_MESG_FROM_AAA, IKE_AAA_CONT_LOGIN
ISAKMP:(1023):Old State = IKE_XAUTH_AAA_CONT_LOGIN_AWAIT New State = IKE_XAUTH_SET_SENT

The client request configuration attributes now and configuration mode proceeds as usual.

ISAKMP: Config payload REQUEST
ISAKMP:(1023):checking request:
ISAKMP: IP4_ADDRESS
ISAKMP: IP4_NETMASK
ISAKMP: IP4_DNS
ISAKMP: IP4_NBNS
ISAKMP: ADDRESS_EXPIRY
ISAKMP: MODECFG_BANNER
ISAKMP: MODECFG_SAVEPWD
ISAKMP: DEFAULT_DOMAIN
ISAKMP: SPLIT_INCLUDE
ISAKMP: SPLIT_DNS
ISAKMP: PFS
ISAKMP: MODECFG_BROWSER_PROXY
ISAKMP: BACKUP_SERVER
ISAKMP: APPLICATION_VERSION
ISAKMP: FW_RECORD
ISAKMP: MODECFG_HOSTNAME
ISAKMP: CONFIG_MODE_UNKNOWN Unknown Attr: 0x7005

AAA/AUTHOR (0x30): Pick method list 'AUTHOR_RADIUS'
ISAKMP/author: Author request for group EZVPNsuccessfully sent to AAA
ISAKMP:(1023):Input = IKE_MESG_FROM_PEER, IKE_CFG_REQUEST
ISAKMP:(1023):Old State = IKE_P1_COMPLETE New State = IKE_CONFIG_AUTHOR_AAA_AWAIT

RADIUS/ENCODE(00000030):Orig. component type = VPN_IPSEC
RADIUS: AAA Unsupported Attr: interface [174] 11
RADIUS: 31 33 36 2E 31 2E 31 30 30 [136.1.100]
RADIUS(00000030): Config NAS IP: 150.1.3.3
RADIUS/ENCODE(00000030): acct_session_id: 46
RADIUS(00000030): sending
ISAKMP:(1023):Input = IKE_MESG_INTERNAL, IKE_PHASE1_COMPLETE
ISAKMP:(1023):Old State = IKE_CONFIG_AUTHOR_AAA_AWAIT New State = IKE_CONFIG_AUTHOR_AAA_AWAIT

The router once again authenticates the group name with the RADIUS server. This time, it looks for authorization attributes to prepare a response to the client.

RADIUS(00000030): Send Access-Request to 10.0.0.100:1645 id 1645/52, len 103
RADIUS: authenticator D5 03 85 B5 36 F4 30 D5 - 1A 12 E3 DE DA A5 5E 10
RADIUS: User-Name [1] 7 "EZVPN"
RADIUS: User-Password [2] 18 *
RADIUS: Calling-Station-Id [31] 15 "136.1.100.200"
RADIUS: NAS-Port-Type [61] 6 Virtual [5]
RADIUS: NAS-Port-Type [61] 6 Virtual [5]
RADIUS: NAS-Port [5] 6 0
RADIUS: NAS-Port-Id [87] 13 "136.1.100.3"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: NAS-IP-Address [4] 6 150.1.3.3
RADIUS: Received from id 1645/52 10.0.0.100:1645, Access-Accept, len 145
RADIUS: authenticator 0B 8B BA 22 EB DF BF 31 - 56 5A 30 EB C0 7B 77 FA
RADIUS: Vendor, Cisco [26] 29
RADIUS: Cisco AVpair [1] 23 "ipsec:addr-pool=EZVPN"
RADIUS: Vendor, Cisco [26] 32
RADIUS: Cisco AVpair [1] 26 "ipsec:inacl=SPLIT_TUNNEL"
RADIUS: Service-Type [6] 6 Outbound [5]
RADIUS: Tunnel-Type [64] 6 01:ESP [9]
RADIUS: Tunnel-Password [69] 21 01:*
RADIUS: Framed-IP-Address [8] 6 255.255.255.255
RADIUS: Class [25] 25
RADIUS: 43 41 43 53 3A 30 2F 31 38 37 36 30 2F 39 36 30 [CACS:0/18760/960]
RADIUS: 31 30 33 30 33 2F 30 [10303/0]
RADIUS(00000030): Received from id 1645/52
ISAKMP:(1023):attributes sent in message:
Address: 0.2.0.0

After this, the negotiations proceed as usual, finishing with establishment of IPSec SA.

RADIUS Authorization with ASA

The steps below are shown in the logical sequence and we’ll discuss the actual flow of RADIUS requests after the outline. Unlike the IOS router, the firewall stores the group profile using a custom password. You specify this password when configuring the group-policy as external. The policy attributes are specified using a special set of Altiga RADIUS attributes. ASA firewall extended this set by adding new names and deprecating some older configuration options.

Step 1:
The firewall accepts incoming connection and maps it to a local tunnel-group.. Once the tunnel-group is found, the group-policy name associated with this tunnel-group is extracted. If the policy is locally configured, the firewall already has all authorization attributes on hand. If the policy is external, the firewall uses the policy name and the policy authentication password to contact the remote server, i.e. the RADIUS host. If the authentication was successful, the server returns authorization attributes and the firewall stores them locally.

Step 2:
If the tunnel-group requires user authentication, it prompts the use for Xauth credentials. Once the user enters them, the firewall authenticates the user using the configured server group (local or remote).

2.1) If user authentication is performed locally, the firewall obtains the authorization attributes from user settings (username ... attributes). Additionally, there could be a group-policy associated with the user (user-specific group-policy). If the policy is local, attributes are immediately available. If the policy is external, the firewall again authenticates with the remote AAA server, using the policy name and configured password. In case of successful authentication, the remote server will return authorization attributes.

2.2) If user authentication is performed externally, the firewall queries the remote AAA server. If the authentication was successful, a number of authorization attributes is returned. Among them, there could be an IETF RADIUS attribute number 25 named “Class”. This attribute value must be in format “OU=Policy_Name;” (OU in upper case, string terminated by semicolon). The firewall parses this RADIUS attribute value (if any) and uses the “Policy_Name” to find a group-policy. This group-policy is user-specific, and in turn may be either local or external. If the policy is external, it’s in turn downloaded from the remote server.

Step 3:
Now the firewall combines all attributes learned at Step 1 and Step 2. User-specific attributes (values associated with the user locally or in the AAA server) take preference over user group-policy (group-policy associated with the user either locally or via RADIUS “Class” attribute). The user-specific group-policy settings take precedence over the group-policy associated with the tunnel-group. Lastly, the attributes defined in the default system group-policy (DfltGrpPolicy) are used to “fill in the gaps”.

As usual, the group profiles stored in the RADIUS server are regular users. However, unlike the IOS case, you may set any password you want for these users, and specify the same password in the ASA configuration. Keep in mind that ASA firewall uses the same set of RADIUS attributes as VPN 3000 appliance did (there are some incompatibilities though). You may find the full listing of the attributes in the ASA firewall VPN configuration guide appendix here Configuring an External Server for Security Appliance User Authorization

Now, the actual order used by the firewall to authorize the settings is a bit different. First, the RADIUS server is not queried until the client returns Xauth credentials. At this point, the firewall authenticates the Xauth user, possibly querying the external server. If the user attributes contain the Class attribute among them, the firewall may query the AAA server for the group-policy attributes (if the policy is not local). Only after this, the appliance will ultimately authorize the group-policy defined in the tunnel-group with the RADIUS server. This sequence is different from the one used in IOS routers, because IOS may need RADIUS attributes for ISAKMP authentication, i.e. download the group pre-shared key. This is why IOS queries AAA server in the very beginning of IKE exchange.

A few words about Group Lock feature in the ASA firewall. The ASA firewall uses special Altiga RADIUS attribute called Tunnel-Group-Lock. This attribute specifies the name of the tunnel group that the user is allowed to log into. The attribute is similar to User-VPN-Group attribute used in IOS routers. Notice that this differs from the Group Lock feature used previously in VPN 3000 appliances.

Debugging Output for IOS RADIUS Policy Download

Now let’s have a look at the RADIUS debugging output for the remote user connecting to the ASA firewall configured as an ezVPN server. The following output is the result of tw debugging commands: debug radius all and debug crypto isakmp 10. The first packet from the client starts IKE AM exchange as usual. The connection lands on the tunnel-group EZVPN and the firewall finds a matching policy entry. Everything else proceeds as usual, until the moment of Phase 1.5

 [IKEv1]: IP = 136.1.100.200, IKE_DECODE RECEIVED Message (msgid=0) with 
payloads : HDR + SA (1) + KE (4) + NONCE (10) + ID (5) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 849
[IKEv1 DEBUG]: IP = 136.1.100.200, processing SA payload
[IKEv1 DEBUG]: IP = 136.1.100.200, processing ke payload
[IKEv1 DEBUG]: IP = 136.1.100.200, processing ISA_KE payload
[IKEv1 DEBUG]: IP = 136.1.100.200, processing nonce payload
[IKEv1 DEBUG]: IP = 136.1.100.200, processing ID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, Received xauth V6 VID
[IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, Received DPD VID
[IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, Received Fragmentation VID
[IKEv1 DEBUG]: IP = 136.1.100.200, IKE Peer included IKE fragmentation capability flags: Main Mode: True Aggressive Mode: False
[IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, Received NAT-Traversal ver 02 VID
[IKEv1 DEBUG]: IP = 136.1.100.200, processing VID payload
[IKEv1 DEBUG]: IP = 136.1.100.200, Received Cisco Unity client VID
[IKEv1]: IP = 136.1.100.200, Connection landed on tunnel_group EZVPN
[IKEv1 DEBUG]: Group = EZVPN, IP = 136.1.100.200, processing IKE SA payload
[IKEv1 DEBUG]: Group = EZVPN, IP = 136.1.100.200, IKE SA Proposal # 1, Transform # 10 acceptable Matches global IKE entry # 1

Now the firewall starts Xauth transactions. The client responds with credentials, and the firewall attempts authentication with the RADIUS server. The firewall sends the name “XAUTH_USER” along with the password of “CISCO”.

[IKEv1]: IP = 136.1.100.200, IKE_DECODE SENDING Message (msgid=cdc0c17f) with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 68
[IKEv1]: IP = 136.1.100.200, IKE_DECODE RECEIVED Message (msgid=cdc0c17f) with payloads : HDR + HASH (8) + ATTR (14) + NONE (0) total length : 87

RADIUS packet decode (authentication request)

--------------------------------------
Raw packet data (length = 160).....
01 00 00 a0 df 2c f5 8a fb 18 71 56 d7 c4 ad e2 | .....,....qV....
73 30 a9 2e 01 0c 58 41 55 54 48 5f 55 53 45 52 | s0....XAUTH_USER
02 12 a7 99 79 db cb 12 41 fb bc 53 30 b2 60 b7 | ....y...A..S0.`.
ae bb 05 06 00 00 f0 00 06 06 00 00 00 02 07 06 | ................
00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 2e | ......136.1.123.
31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 30 | 12..136.1.100.20
30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e 31 | 0=.....B.136.1.1
30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 00 | 00.200....{..$..
00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 70 | ....ip:source-ip
3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 0d a2 | =136.1.100.200..

The server responds and you can see the RADIUS Class attribute in the response. Notice that the response also contains the IP address 20.0.0.100 to be assigned to the client.

RADIUS packet decode (response)

--------------------------------------
Raw packet data (length = 71).....
02 00 00 47 2e 49 12 20 d5 49 31 ca 26 b5 a8 68 | ...G.I. .I1.&..h
8a f6 c7 2e 08 06 14 00 00 64 19 10 4f 55 3d 45 | .........d.. OU=E
5a 56 50 4e 5f 55 53 45 52 3b 19 1d 43 41 43 53 | ZVPN_USER;..CACS
3a 30 2f 31 38 63 37 36 2f 38 38 30 31 37 62 30 | :0/18c76/88017b0
63 2f 36 31 34 34 30 | c/61440

Parsed packet data.....
Radius: Code = 2 (0x02)
Radius: Identifier = 0 (0x00)
Radius: Length = 71 (0x0047)
Radius: Vector: 2E491220D54931CA26B5A8688AF6C72E
Radius: Type = 8 (0x08) Framed-IP-Address
Radius: Length = 6 (0x06)
Radius: Value (IP Address) = 20.0.0.100 (0x14000064)
Radius: Type = 25 (0x19) Class
Radius: Length = 16 (0x10)
Radius: Value (String) =
4f 55 3d 45 5a 56 50 4e 5f 55 53 45 52 3b | OU=EZVPN_USER;
Radius: Type = 25 (0x19) Class
Radius: Length = 29 (0x1D)
Radius: Value (String) =
43 41 43 53 3a 30 2f 31 38 63 37 36 2f 38 38 30 | CACS:0/18c76/880
31 37 62 30 63 2f 36 31 34 34 30 | 17b0c/61440
rad_procpkt: ACCEPT

Now the firewall parses the class attribute and extract the group policy name “EZVPN_USER”. Since this policy is defined as external, another request is made to the AAA server. The server responds with the attributes corresponding to this group policy.

RADIUS packet decode (authentication request)

--------------------------------------
Raw packet data (length = 160).....
01 01 00 a0 cf 5c 65 3a eb 48 e1 06 c7 f4 1d 92 | .....\e:.H......
63 60 19 de 01 0c 45 5a 56 50 4e 5f 55 53 45 52 | c`....EZVPN_USER
02 12 31 26 3f 4c 0c 58 cb 9b 20 ab 48 76 d8 70 | ..1&?L.X.. .Hv.p
a3 03 05 06 00 00 00 00 06 06 00 00 00 02 07 06 | ................
00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 2e | ......136.1.123.
31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 30 | 12..136.1.100.20
30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e 31 | 0=.....B.136.1.1
30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 00 | 00.200....{..$..
00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 70 | ....ip:source-ip
3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 a7 a0 | =136.1.100.200..

RADIUS packet decode (response)

--------------------------------------
Raw packet data (length = 101).....
02 01 00 65 b7 d9 60 2d 8f a5 a4 cd 1c bb 76 1e | ...e..`-......v.
d3 44 00 ba 1a 19 00 00 0c 04 1b 13 53 50 4c 49 | .D..........SPLI
54 5f 54 55 4e 4e 45 4c 5f 55 53 45 52 1a 0c 00 | T_TUNNEL_USER...
00 0c 04 37 06 00 00 00 01 1a 0d 00 00 0c 04 55 | ...7...........U
07 45 5a 56 50 4e 08 06 ff ff ff ff 19 19 43 41 | .EZVPN........CA
43 53 3a 30 2f 31 38 63 37 37 2f 38 38 30 31 37 | CS:0/18c77/88017
62 30 63 2f 30 | b0c/0

The attributes contain split-tunnel policy definition and the Tunnel-Group-Lock attribute with the value of “EZVPN”.

Parsed packet data.....
Radius: Code = 2 (0x02)
Radius: Identifier = 1 (0x01)
Radius: Length = 101 (0x0065)
Radius: Vector: B7D9602D8FA5A4CD1CBB761ED34400BA
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 25 (0x19)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 27 (0x1B) Split-Tunnel-Inclusion-List
Radius: Length = 19 (0x13)
Radius: Value (String) =
53 50 4c 49 54 5f 54 55 4e 4e 45 4c 5f 55 53 45 | SPLIT_TUNNEL_USE
52 | R

Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 55 (0x37) Split-Tunneling-Policy
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 1 (0x0001)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 13 (0x0D)
Radius: Vendor ID = 3076 (0x00000C04)

Radius: Type = 85 (0x55) The tunnel group that tunnel must be associated with
Radius: Length = 7 (0x07)
Radius: Value (String) =
45 5a 56 50 4e | EZVPN
Radius: Type = 8 (0x08) Framed-IP-Address
Radius: Length = 6 (0x06)
Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)
Radius: Type = 25 (0x19) Class
Radius: Length = 25 (0x19)
Radius: Value (String) =
43 41 43 53 3a 30 2f 31 38 63 37 37 2f 38 38 30 | CACS:0/18c77/880
31 37 62 30 63 2f 30 | 17b0c/0
rad_procpkt: ACCEPT

Now the firewall requests AAA attributes associated with the tunnel-group group-policy. This group-policy is defined as external in the firewall, and thus the appliance sends the respective name to the AAA server.

RADIUS packet decode (authentication request)

--------------------------------------
Raw packet data (length = 161).....
01 02 00 a1 bf 8c d5 ea db 78 51 b6 b7 24 8d 42 | .........xQ..$.B
53 90 89 8e 01 0d 45 5a 56 50 4e 5f 47 52 4f 55 | S.....EZVPN_GROU
50 02 12 59 a6 eb 66 f7 79 8b 26 16 cb 0e cd ab | P..Y..f.y.&.....
23 9b b7 05 06 00 00 00 00 06 06 00 00 00 02 07 | #...............
06 00 00 00 01 1e 0e 31 33 36 2e 31 2e 31 32 33 | .......136.1.123
2e 31 32 1f 0f 31 33 36 2e 31 2e 31 30 30 2e 32 | .12..136.1.100.2
30 30 3d 06 00 00 00 05 42 0f 31 33 36 2e 31 2e | 00=.....B.136.1.
31 30 30 2e 32 30 30 04 06 88 01 7b 0c 1a 24 00 | 100.200....{..$.
00 00 09 01 1e 69 70 3a 73 6f 75 72 63 65 2d 69 | .....ip:source-i
70 3d 31 33 36 2e 31 2e 31 30 30 2e 32 30 30 da | p=136.1.100.200.
a1 | .

The serve responds with the tunnel group policy attributes. The attributes are decoded in the output below. You can see the split tunnel access-list, which is overridden by the user group-policy setting though.

RADIUS packet decode (response)

--------------------------------------
Raw packet data (length = 131).....
02 02 00 83 b8 c5 22 ec c6 29 37 c0 6d c1 cd ae | ......"..)7.m...
23 4f 36 bc 1a 0c 00 00 0c 04 0b 06 00 00 00 04 | #O6.............
1a 0c 00 00 0c 04 0d 06 00 00 00 01 1a 14 00 00 | ................
0c 04 1b 0e 53 50 4c 49 54 5f 54 55 4e 4e 45 4c | ....SPLIT_TUNNEL
1a 0c 00 00 0c 04 05 06 0a 00 00 64 1a 0c 00 00 | ...........d....
0c 04 37 06 00 00 00 01 1a 0c 00 00 0c 04 3d 06 | ..7...........=.
14 00 00 0c 08 06 ff ff ff ff 19 19 43 41 43 53 | ............CACS
3a 30 2f 31 38 63 37 38 2f 38 38 30 31 37 62 30 | :0/18c78/88017b0
63 2f 30 | c/0

Parsed packet data.....
Radius: Code = 2 (0x02)
Radius: Identifier = 2 (0x02)
Radius: Length = 131 (0x0083)
Radius: Vector: B8C522ECC62937C06DC1CDAE234F36BC
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 11 (0x0B) Tunnelling-Protocol
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 4 (0x0004)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 13 (0x0D) IPSec-Authentication
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 1 (0x0001)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 20 (0x14)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 27 (0x1B) Split-Tunnel-Inclusion-List
Radius: Length = 14 (0x0E)
Radius: Value (String) =
53 50 4c 49 54 5f 54 55 4e 4e 45 4c | SPLIT_TUNNEL

Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 5 (0x05) Primary-DNS
Radius: Length = 6 (0x06)
Radius: Value (IP Address) = 10.0.0.100 (0x0A000064)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 55 (0x37) Split-Tunneling-Policy
Radius: Length = 6 (0x06)
Radius: Value (Integer) = 1 (0x0001)
Radius: Type = 26 (0x1A) Vendor-Specific
Radius: Length = 12 (0x0C)
Radius: Vendor ID = 3076 (0x00000C04)
Radius: Type = 61 (0x3D) Group-giaddr
Radius: Length = 6 (0x06)
Radius: Value (IP Address) = 20.0.0.12 (0x1400000C)
Radius: Type = 8 (0x08) Framed-IP-Address
Radius: Length = 6 (0x06)
Radius: Value (IP Address) = 255.255.255.255 (0xFFFFFFFF)
Radius: Type = 25 (0x19) Class
Radius: Length = 25 (0x19)
Radius: Value (String) =
43 41 43 53 3a 30 2f 31 38 63 37 38 2f 38 38 30 | CACS:0/18c78/880
31 37 62 30 63 2f 30 | 17b0c/0
rad_procpkt: ACCEPT

Jan
07

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:

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

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

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.255

Now 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.200

Now 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 drop

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:

inacl
interface-config
outacl
route
rte-fltr-in
rte-fltr-out
sub-policy-In
sub-policy-Out
policy-route
prefix

For more information on IKE and Locall AAA (and configuration examples) refer to the following link:

IPsec Virtual Tunnel Interface

Subscribe to INE Blog Updates