Nov
25

Have you ever been on your GradedLabs rack of equipment and wanted to test a particular feature or set of configurations, but you certainly do not want to keep these changes on the rack? Perhaps this is because you are right in the middle of solving a Volume 2 lab and you certainly cannot have that configuration impacted.

Thanks to the very handy config replace command, you can easily rollback almost instantly to your previous saved configuration after your experimenting. Here is a demonstration of just how simple this is. Enjoy, and let us give thanks for all there is to learn on blog.ine.com! :-) I also want to thank my good friend Keith Barker for first showing me this one.

Rack29R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Rack29R1(config)#hostname TEST
TEST(config)#interface fastethernet0/0
TEST(config-if)#ip address 1.2.3.4 255.0.0.0
TEST(config-if)#no shut
TEST(config-if)#end
TEST#
Nov 25 09:09:58.856: %LINK-3-UPDOWN: Interface FastEthernet0/0, changed state to
up
Nov 25 09:09:59.173: %SYS-5-CONFIG_I: Configured from console by console
TEST#configure terminal
Nov 25 09:10:01.404: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEtherne
t0/0, changed state to up
TEST#config replace nvram:startup-config force
Total number of passes: 1
Rollback Done
Rack29R1#
Nov 25 09:10:08.644: Rollback:Acquired Configuration lock.
Nov 25 09:10:17.827: %LINK-5-CHANGED: Interface FastEthernet0/0, changed state t
o administratively down
Nov 25 09:10:18.829: %LINEPROTO-5-UPDOWN: Line protocol on Interface FastEtherne
t0/0, changed state to down
Rack29R1#
Nov 25 09:10:22.727: %PARSER-3-CONFIGNOTLOCKED: Unlock requested by process '3'.
Configuration not locked.
Rack29R1#
Rack29R1#configure terminal
Enter configuration commands, one per line.  End with CNTL/Z.
Rack29R1(config)#hostname TEST
TEST(config)#interface fastethernet0/0
TEST(config-if)#ip address 1.2.3.4 255.0.0.0
TEST(config-if)#no shut
TEST(config-if)#end
TEST#
TEST#config replace nvram:startup-config force
Total number of passes: 1
Rollback Done
Rack29R1#
Rack29R1#show run interface fa0/0
Building configuration...
Current configuration : 83 bytes
!
interface FastEthernet0/0

no ip address
shutdown
duplex auto
speed auto
end

Rack29R1#

Mar
31

For many of you geeks and nerds out there like me (I'll take a poll as to which one is better at another time), you've worked with some *NIX flavor for many years now. For others of you, you have most likely dabbled with various Linux distro's and have come to know commands as needed. One extremely powerful tool that you may or may not have come across during your years is SED or the Stream Editor (sometimes referred to as the String Editor as well). This tool can take input from stdin and manipulate it as it leaves via stdout.

For those of you that have used SED in the past, you will certainly notice some similarities to the Cisco set of commands known fondly to many voice folks as Voice Translation Rules, and given your ability to pick out the differences, may help you in your quick adaptation to Cisco's iteration of this tool.

For those of you that have not ever used this tool, take no worry. For in these next series of blog posts I will attempt to break down not only the components of Voice Translation Rules, but of the overall science of Digit Manipulation in IOS, into bite-sized chunks that will help you to digest it much easier.

Here in this first installation of the blog series, I won't so much go into practical application along with placement, debugging and the big picture, as I will seek to first help you out with the laws that must be conformed to, in a single rule within the overarching ruleset. Then in near future installations, I will provide not only the framework for wherein this ruleset applies, but also how it affects other forms of digit manipulation as well as detailed debugging to give you a full pragmatic understanding of the power of Digit Manipulation in IOS.

So to begin with, a quick understanding of what we are attempting to accomplish is probably in line. We desire to take a string of digits, in whatever form they are given to us, and change them to something different. We may wish to change a small part of the digits, or the entirety of them. We may not wish to change anything at all about the digits themselves, but instead possibly something about them, namely their Type and Plan attributes.

In order to begin using Voice Translation Rules, we must start out with an understanding of how they work, that is to say "What laws govern them? What laws must we follow in order to obtain our desired output?".

The First Law of Voice Translation Rules we will very basically see is that our beginning matched number, and our output translated number, must both be surrounded in (or delineated by) a set of forward slashes. So the syntax goes:

voice translation-rule 1
rule 1 /matched-digit-string/ /translated-digit-string/

So it would stand to reason that:

voice translation-rule 1
rule 1 /6145551212/ /6148682121/

Would result in the number 6145551212 being translated to 6148682121 - and that would be correct. We also have a handy test tool to assist us in deciding if what we put in and desire to get out - works the way we intended it to. We run it from exec mode (not global config mode) - and it goes like this:

VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212 Translated number: 6148682121
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

VORack52R1#

So that's the first bit. Not too overly complicated is it? Not really - but as we add flexibility in what we can match and what we can do with what we match, you will begin to see the amount of complexity go up. Really what you may see is the amount of readability go down - but again just remember - bite-sized-chunks - after all it's the only way to eat an elephant (INE does not condone the harming of animals in any way - it's just a colloquialism).

So next let's take a look at things a step further. Notice in my above example I didn't do anything to change the prefixed digits of 614, I seemingly desired for them to stay the same. That being the case, did I need to even include them? What if I simply omitted them altogether? Would everything still match and result in the same output? Let's take that question/theory for a spin:

VORack52R1#sh run | s voice t
voice translation-rule 1
rule 1 /5551212/ /8682121/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212 Translated number: 6148682121
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

VORack52R1#

It certainly looks like everything still worked just fine. But why did it? Voice Translation-Rules don't manipulate data that they are not given to match on. In other words, if the data isn't included the beginning matched number, then it is simply left alone (e.g. whatever came in - goes out - untouched). OK, you might say - but why did the matched number of /5551212/ allow a match on a string of 6145551212 - the string in the matched number didn't include the prefix of 614 - so why did it allow the match? Simple answer: Because we never told it that it wasn't allowed to. Well - can we tell it that it isn't allowed to? Sure - this brings us to our Second Law of Voice Translation Rules - namely the ability to use Regular Expressions (or "regex") in the matched number. NOTE: Regex can only be used in matching numbers, not in the translated number. This is the same in IOS as it is in CUCM. Most regular expressions apply. As a reminder, I will very, very briefly excerpt a few more commonly used elements here:

? Matches the preceding element zero or one time.

+ Matches the preceding element one or more times.

^ Matches the beginning of a literal string.

$ Matches the end of a literal string.

| Defines that what goes directly before and after this symbol is a Boolean OR.

\(  \) Defines a marked subexpression. The string matched within the parentheses can be recalled later.

So if we go back to our most recent example with only 7 digits beginning with 555 to match from, and give it a ^ before the matched number, we should see that our input of 10 digits beginning with 614, will simply not match:

VORack52R1#sh run | s voice t
voice translation-rule 1
rule 1 /^5551212/ /8682121/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
6145551212 Didn't match with any of rules
VORack52R1#

And that's exactly what we see. However if we modify our input number to only 7 digits beginning with 555, we should still have a match and a subsequent translate:

VORack52R1#test voice translation-rule 1 5551212
Matched with rule 1
Original number: 5551212 Translated number: 8682121
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

VORack52R1#

And of course indeed we do.

So now let's move on and take a look at that last powerful expression I posted above - the one with open and close parenthesis, and those backslashes preceding each parenthesis. The backslashes are typical in most scripting languages to escape something that could otherwise be interpreted by the parser as part of the string. We need to inform the parser that it is not part of the string - but in fact an operator designed to do something. In this case it is designed to set apart a section or "set" of our string, that we wish to later recall. So let's go back to the example of 10 digits that begin (and only begin) with 614, and then set about to change only the 555 to 868, while preserving whatever 4 trailing "Subscriber" digits come in following the 555 prefix. To do that we will include the 614 along with a ^ to denote that the string must begin with a 614. Then we will "set apart" the part of the number beginning with 555 and ending in any 4 digits. Finally we will change the 555 to 868, and reuse whatever 4 Subscriber digits came into the original string. This brings us to a very important Third Law of Voice Translation Rules, which is that in the translated number portion of the rule - a backslash has a very different role: The Backslash is always followed by a Numeral - and that numeral defines which "section" or "set" from the original matched number is now being "recalled" to this current position. You may have multiple backslash\numerals - and each one independently of the others recalls whatever section is represented by a numeral. It is best to keep things simple and have as few as needed - but complexity can easily be undertaken if the desired outcome requires it. Here we will demonstrate this with a simple single "set" in the matched number, followed by a recall of that set to the translated number, and then of course the "test" to prove the theory.

 VORack52R1#sh run | s voice t
voice translation-rule 1
rule 1 /^614555\(....\)/ /614868\1/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212 Translated number: 6148681212
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

VORack52R1#

Again we could get a bit more complex with multiple "sets" and "recalls" in the matched and translated number respectively, and yet yield the same resultset:


VORack52R1#sh run | s voice t
voice translation-rule 1
rule 1 /^\(614\)555\(....\)/ /\1868\2/
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 6145551212
Matched with rule 1
Original number: 6145551212 Translated number: 6148681212
Original number type: none Translated number type: none
Original number plan: none Translated number plan: none

VORack52R1#

Again - we simply created 2 sets, and then when the placeholder came time in the translated number to recall the contents of that first or second set, we did so with a \1 or \2, along with the other normal string digits (868) we wished to replace.

Another thing we can do is to, as I mentioned above, not change the matched number into anything, but rather to leave it be use the Voice Translation Rules to change the Numbering Type and Plan. The format is a bit odd - it is:

<span style="font-family: sans-serif, 'Times New Roman', 'Bitstream Charter', Times, serif;"><span style="border-collapse: collapse; -webkit-border-horizontal-spacing: 2px; -webkit-border-vertical-spacing: 2px;">/<em>matched-number</em>/ /<em>translated-number</em>/ type <em>matching-type translated-type</em> plan <em>matching-plan translated-plan</em></span></span>

So here in this example we have a common US rural carrier issue, namely that the carrier will refuse the call if both the carrier international prefix string of "011" and also the numbering type and plan of "international" and "isdn" are all included in the called party IE. To resolve this we simply need to allow any digits that come in, to go out, while at the same time changing the type and plan from "international" and "isdn" to  "unknown" and "unknown". This will do the trick for some carriers.

VORack52R1#sh run | s voice t
voice translation-rule 1
rule 1 // // type international unknown plan isdn unknown
VORack52R1#
VORack52R1#
VORack52R1#test voice translation-rule 1 011442055551212 type international plan isdn
Matched with rule 1
Original number: 011442055551212 Translated number: 011442055551212
Original number type: international Translated number type: unknown
Original number plan: isdn Translated number plan: unknown

VORack52R1#

So that will end our first dive into Voice Translation Rules - and beginning into the much bigger picture of Digit Manipulation in IOS. Stay tuned in the very near future as I will paint (with pretty visuals) a much deeper understanding of both as we take both a more detailed look into many of the components, as well as broader overall view as to where it's best to use each component, and how they all fit and play nicely together.

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

Apr
22

Hi everyone,

we have just uploaded the initial update of IEWB-SC VOL1 "VPN" section to all subscribed accounts. The update contains 15 new labs listed below:

LAN-to-LAN VPN between IOS and ASA
IPsec and NAT Interaction in ASA Firewall
Peer Authentication using Digital Signatures
ASA Tunnel Group Names
ASA Certificate Mapping Rules
Filtering traffic inside LAN-to-LAN tunnels
LAN-to-LAN tunnel between IOS Routers
IOS IPsec NAT Traversal
IOS IKE Aggressive Mode
VPN between Overlapping Subnets
IOS VPN with Digital Signatures Authentication
IOS Certificate Access Lists
Virtual Tunnel Interfaces
GRE over IPsec
DMVPN

The following labs are in process of being developed should be available soon. Notice that there might be more labs than currently are on the list.

IOS ezVPN Server
IOS ezVPN Server with RADIUS
IOS ezVPN Server with Digital Certificates
IOS ezVPN Remote
ASA ezVPN Server
ASA ezVPN Server with RADIUS
ASA ezVPN Server with Digital Certificates
IOS Clientless SSL VPN
IOS SSL VPN
ASA SSL VPN
ASA Clientless SSL VPN
IOS PPTP
ASA L2TP over IPsec
IPSec High Availability
GET VPN

The next thing you guys would see updated is the long-awaited IEWB-RS VOL1 v5.0 "BGP" section :)

Have fun!

Apr
19

General Logic Overview

When establishing a VPN tunnel, ASA firewall matches tunnel-group names based on the following criteria list:

1) Using the IKE ID presented by the remote peer. It may be an IP address (default) or hostname. In some cases this might be an ezVPN group name, for example when you are using Cisco ezVPN client or ezVPN Remote feature.
2) Using the OU (Organization Unit) field from the DN found in digital certificate presented by the peer OR by using the certificate mapping rules. This only works when ISAKMP phase uses digital signatures for authentication. Certificate mapping rules translate the DN (distinguished name) found in the certificate to the tunnel-group name.
3) Using the remote endpoint’s IP address. It’s the last resort rule, and this is the only way to match the identity with PSK (pre-shared keys) and IKE Main Mode.

Recall that IKE uses either of two modes of operation for Phase 1: Main Mode (default) and Aggressive Mode:

a) Main Mode (MM), which is mandatory per the RFC - creates an encrypted channel before exchanging the identities.
b) Aggressive Mode (AM), which is quicker than Main Mode, exchanges endpoint IDs in “clear text”, while performing DH (Diffie Hellman) exchange and establishing the secure channel. AM is less secure than MM is thus should be less preferred. However, there are some properties that make AM uniquely useful.

IKE MM with PSK

There are some important consequences of MM behavior, when implementing authentication based on pre-shared keys (PSK). When pre-shared keys are used for authentication, they are also used to generate the shared encryption key for ISAKMP SA (along with the DH generated key). This feature is very important to prevent man-in-the middle attacks. When ISAKMP responder receives a MM proposal from initiator and choses authentication based on pre-shared keys, it should generate the shared encryption key. This procedure requires knowing the PSK of the remote peer in advance. However, the responder does NOT know the IKE ID of the initiator yet, only its IP address. Therefore, the only way to select the proper pre-shared key in MM is by looking the key in the database based on the initiator’s IP address. Even if you use of hostnames for IKE IDs with PSK authentication, the keys and tunnel-group names are still matched based on the IP addresses. This is the unique “feature” of ISAKMP MM with PSK.

IKE MM with digital signatures

Now consider the case when you are using IKE MM along with digital signatures (RSA sigs) authentication. In this situation, session encryption key is not derived based on the pre-shared authentication key. Thus, the respondent that accepts the policy based on digital signatures may delay the proper tunnel-group selection until it learns the IKE ID of the initiator. More than that, it may use the information from the DN field of the digital certificate presented by the initiator for more detailed matching. With the default configuration, the subject’s OU field in the certificate is used to match the tunnel group names, but it is possible to set up flexible mapping rules.

In ASA firewall, the following default commands enable tunnel-group name lookup based on the OU (first) than IKE-ID (if present) and finally the Peer IP address:

tunnel-group-map enable ou
tunnel-group-map enable ike-id
tunnel-group-map enable peer-ip

IKE AM and names matching

When the responding node receives an AM proposal, the proposal already contains the initiator's IKE ID, regardless of the authentication method selected. The IKE ID might be an IP address or hostname or just any text string - e.g. ezVPN group name. The responder may use it to match the local tunnel-group and pre-shared key if needed. Thus, you may utilize tunnel-group names based on hostnames with IKE AM even with PSK authentication.

Activating IKE AM

IKE AM is automatically enabled with some VPN features, such as ezVPN remote. In order to engage AM negotiation in ASA firewalls manually, use the command crypto map [TAG] [SEQ#] set phase1-mode aggressive. Enabling this feature in IOS is a bit more trickier. You should configure an ISAKMP profile first and then use it with a crypto map similar to the following:

crypto isakmp profile AGGRESSIVE
initiate mode aggressive
self-identity fqdn
keyring default
!
crypto map VPN isakmp-profile AGGRESSIVE
crypto map VPN 10 ipsec-isakmp

You may globally disable AM in Cisco IOS router using the command crypto isakmp aggressive-mode disable or using the command isakmp am-disable in ASA firewall. This will prevent the devices from ever accepting or initiaing any IKE AM connections.

Fallback Matching

What happens if none of the configured tunnel groups matches? In this case, the firewall would use the default group that is always present in the system: DefaultRAGroup. Thus, if you don’t have a specific group configured for the remote endpoint, but the authentication using the default group succeeds, the system will use the default policy for the new tunnel. In case you wonder, you may change the default tunnel-group name using the command tunnel-group-map default-group <NAME> and specify your own group.

Certificate Mapping Rules

When using digital signatures authentication, ASA firewall supports certificate mapping rules to translate issuer and subject names in the certificate to the tunnel-group name. The rules are configured using the command crypto ca certificate map [<NAME>] <SEQ#>. If no name is specified, the default map named DefaultCertificateMap is used for this purpose. Every entry in this map matches either part of issuer or subject DN in the certificate. For example

crypto ca certificate map MYMAP 10
issuer-name attr cn eq IESERVER1
subject-name co R3

You may match the DN as a whole string, without specifying any particular attribute like the second line in the above example does. When you have the map configured, you need to perform the following two steps:

1) Enable the mapping rules using the command tunnel-group-map enable rules.
2) Configure certificate map to tunnel-group mapping using the global commands tunnel-group-map [<NAME>] <SEQ#> <Tunnel-Group-Name>.

You may repeat the second step how many times you want to map the particular entry to a tunnel group that exists in the sytem. If you don’t specify the name for the certificate map, the default is DefaultCertificateMap used. Notice that OR logic is implemented by mapping multiple certificate map entries to the same group. Thus, any of the matching entries will result in the incoming session being matched on the same group.

Jan
22

As we well know, one of the best features of Cisco IOS is the parser’s context sensitive help and tab-completion when typing in configuration or verification commands. One of the lesser known features related to this, however, is the ability to view all officially supported commands available in the parser on a per-mode basis on the CLI via the show parser dump command.

show parser dump lists all commands in exec mode, global configuration mode, route-map mode, etc. prefixed by the privilege level of the command. This includes the negation (e.g. “no router rip”) and the default (e.g. “default interface”) in addition to the actual command and its arguments. The advantage of this output is that you can quickly find the complete syntax for a command, or set of commands, just by filtering through the parser dump.

For example let’s take a look at the output of the “show parser dump route-map”, which shows us all commands under the route-map subconfiguration mode.

Router#show parser dump route-map
Mode Name :route-map
0 no description <string>
0 no description
0 no description
0 no match interface <interface>
0 no match interface
0 no match interface
0 no match metric external <1-4294967295> +- <1-4294967295>
0 no match metric external <1-4294967295> +- <1-4294967295>
0 no match metric external <1-4294967295>
0 no match metric external <1-4294967295>
0 no match metric external
0 no match metric <1-4294967295> +- <1-4294967295>
0 no match metric <1-4294967295> +- <1-4294967295>
0 no match metric <1-4294967295>
0 no match metric <1-4294967295>
0 no match metric
[output omitted]
0 default description <string>
0 default description
0 default description
0 default match interface <interface>
0 default match interface
0 default match interface
0 default match metric external <1-4294967295> +- <1-4294967295>
0 default match metric external <1-4294967295> +- <1-4294967295>
0 default match metric external <1-4294967295>
0 default match metric external <1-4294967295>
0 default match metric external
0 default match metric <1-4294967295> +- <1-4294967295>
0 default match metric <1-4294967295> +- <1-4294967295>
0 default match metric <1-4294967295>
0 default match metric <1-4294967295>
0 default match metric
[output omitted]
15 description <string>
15 description
15 description
15 match interface <interface>
15 match interface
15 match interface
15 match metric external <1-4294967295> +- <1-4294967295>
15 match metric external <1-4294967295> +- <1-4294967295>
15 match metric external <1-4294967295>
15 match metric external <1-4294967295>
15 match metric external
15 match metric <1-4294967295> +- <1-4294967295>
15 match metric <1-4294967295> +- <1-4294967295>
15 match metric <1-4294967295>
15 match metric <1-4294967295>
15 match metric
[output omitted]

Note that in the above output the commands are listed redundantly with both the prefixes “no” and “clear”, in addition to the actual command. The number at the beginning of the line is the command’s privilege level, which means that to issue the “no match interface” command you must have at least privilege level 0, but to actually issue the “match interface” command, you must be at privilege level 15.

One way to cut down on unnecessary output, while still keeping it useful, is to filter the output to only include lines that start with “15”, such as follows:

Router#show parser dump route-map | include ^15_
15 description <string>
15 description
15 description
15 match interface <interface>
15 match interface
15 match interface
15 match metric external <1-4294967295> +- <1-4294967295>
15 match metric external <1-4294967295> +- <1-4294967295>
15 match metric external <1-4294967295>
15 match metric external <1-4294967295>
15 match metric external
15 match metric <1-4294967295> +- <1-4294967295>
15 match metric <1-4294967295> +- <1-4294967295>
15 match metric <1-4294967295>
15 match metric <1-4294967295>
15 match metric
15 match tag <0-4294967295>
15 match tag
15 match tag
15 match route-type internal
15 match route-type external type-1
15 match route-type external type-2
15 match route-type external
[output omitted]

From this we can see that there is much less output than before, but we still maintain all the necessary commands we want to see. Here’s another example, where we look for all OSPF related commands at the interface level:

Router#show parser dump interface | include ^15_(.*)ospf
15 ip ospf authentication
15 ip ospf authentication-key
15 ip ospf message-digest-key <1-255>
15 ip ospf network
15 ip ospf cost <1-65535>
15 ip ospf resync-timeout <1-65535>
15 ip ospf hello-interval <1-65535>
15 ip ospf dead-interval
15 ip ospf priority <0-255>
15 ip ospf retransmit-interval <1-65535>
15 ip ospf transmit-delay <1-65535>
15 ip ospf lls
15 ip ospf flood-reduction
15 ip ospf demand-circuit
15 ip ospf mtu-ignore
15 ip ospf database-filter
15 ip ospf <1-65535> area <address> secondaries none
15 ip ospf <1-65535> area <address>
15 ip ospf <1-65535> area <0-4294967295>
15 ip ospf authentication
15 ip ospf authentication-key
15 ip ospf message-digest-key <1-255>
15 ip ospf network
15 ip ospf cost <1-65535>
15 ip ospf resync-timeout <1-65535>
15 ip ospf hello-interval <1-65535>
15 ip ospf dead-interval
15 ip ospf priority <0-255>
15 ip ospf retransmit-interval <1-65535>
15 ip ospf transmit-delay <1-65535>
15 ip ospf lls
15 ip ospf flood-reduction
15 ip ospf demand-circuit
15 ip ospf mtu-ignore
15 ip ospf database-filter
15 ip ospf <1-65535> area <address> secondaries none
15 ip ospf <1-65535> area <address>
15 ip ospf <1-65535> area <0-4294967295>
15 ipv6 ospf authentication ipsec spi <256-4294967295>
15 ipv6 ospf authentication null
15 ipv6 ospf network
15 ipv6 ospf cost <1-65535>
15 ipv6 ospf hello-interval <1-65535>
15 ipv6 ospf dead-interval <1-65535>
15 ipv6 ospf priority <0-255>
15 ipv6 ospf retransmit-interval <1-65535>
15 ipv6 ospf transmit-delay <1-65535>
15 ipv6 ospf flood-reduction
15 ipv6 ospf demand-circuit
15 ipv6 ospf mtu-ignore
15 ipv6 ospf database-filter
15 ipv6 ospf neighbor <address>
15 ipv6 ospf neighbor <address> cost <1-65535>
15 ipv6 ospf neighbor <address> database-filter all out
15 ipv6 ospf neighbor <address>
15 ipv6 ospf neighbor <address> priority <0-255>
15 ipv6 ospf neighbor <address> poll-interval <0-4294967295>
15 ipv6 ospf neighbor <address>
15 ipv6 ospf <1-65535> area <address> instance <0-255>
15 ipv6 ospf <1-65535> area <address>
15 ipv6 ospf <1-65535> area <0-4294967295>

Note that this included both OSPFv2 and OSPFv3 commands (IPv4 vs. IPv6) since I didn’t limit the output just to “ip ospf”. Another great example for this is IPSec related commands in global configuration. These commands generally include the words “crypto”, “ipsec”, or “isakmp”. With the below output we can look for any iteration of this. Note that since the regular expression is fairly complex, the CPUHOG message appears that the exec process is becoming CPU intensive:

Router#show parser dump configure | include ^15_(.*)((crypto)|(ipsec)|(isakmp))

*Jan 19 11:31:52.032: %SYS-3-CPUHOG: Task is running for (2004)msecs, more than (2000)msecs (0/0),process = Exec.
-Traceback= 0x8005B2A4 0x8005B9F8 0x8006911C 0x8006A778 0x8006A250 0x811AB110 0x811AB004 0x811AB570 0x811A470C 0x811A39E8 0x811C3974 0x80244E10 0x80248504
*Jan 19 11:31:54.035: %SYS-3-CPUHOG: Task is running for (4007)msecs, more than (2000)msecs (0/0),process = Exec.
-Traceback= 0x80065318 0x8006A630 0x8006A250 0x811AB110 0x811AB004 0x811AB570 0x811A470C 0x811A39E8 0x811C3974 0x80244E10 0x80248504
*Jan 19 11:31:54.187: %SYS-3-CPUYLD: Task ran for (4156)msecs, more than (2000)msecs (0/0),process = Exec

*Jan 19 11:32:32.538: %SYS-3-CPUHOG: Task is running for (2003)msecs, more than (2000)msecs (0/0),process = Exec.
-Traceback= 0x8006A40C 0x8006A250 0x811AB110 0x811AB004 0x811AB570 0x811A470C 0x811A39E8 0x811C3974 0x80244E10 0x80248504
*Jan 19 11:32:34.541: %SYS-3-CPUHOG: Task is running for (4006)msecs, more than (2000)msecs (0/0),process = Exec.
-Traceback= 0x8006A414 0x8006A250 0x811AB110 0x811AB004 0x811AB570 0x811A470C 0x811A39E8 0x811C3974 0x80244E10 0x80248504
*Jan 19 11:32:34.606: %SYS-3-CPUYLD: Task ran for (4068)msecs, more than (2000)msecs (0/0),process = Exec15 ip nbar port-map ipsec
15 crypto pki token default max-retries
15 crypto pki token default removal timeout
15 crypto pki token default user-pin
15 crypto pki token default secondary config
15 crypto pki token <string>
15 crypto pki authenticate <string>
15 crypto pki enroll <string> interface <string> use <string> password <string>
15 crypto pki enroll <string> interface <string> use <string>
15 crypto pki enroll <string>
15 crypto pki enroll
15 crypto pki import <string> pkcs12 terminal <string>
15 crypto pki import <string> pkcs12 <URL>
15 crypto pki import <string> pem usage-keys exportable terminal <string>
15 crypto pki import <string> pem usage-keys exportable url <URL>
15 crypto pki import <string> pem usage-keys
15 crypto pki import <string> pem
15 crypto pki import <string> certificate
15 crypto pki export <string> pkcs12 terminal <string>
15 crypto pki export <string> pkcs12 <URL>
15 crypto pki export <string> pem terminal 3des <string>
15 crypto pki export <string> pem terminal des
15 crypto pki export <string> pem terminal
15 crypto pki export <string> pem url <URL>
15 crypto pki crl request <string>
15 crypto pki certificate query
15 crypto pki certificate map <string>
15 crypto pki certificate map <string> <1-65535>
15 crypto pki certificate validate <string>
15 crypto ca
15 crypto provisioning petitioner
15 crypto provisioning registrar
15 crypto wui tti
15 crypto engine software ipsec
15 crypto engine nm <0-3>
15 crypto engine onboard Number
15 crypto engine aim Number
15 crypto engine em <0-3>
15 crypto engine slot Number
15 crypto engine accelerator
15 crypto engine accelerator Number
15 crypto key generate rsa usage-keys label <string> modulus <360-2048> exportable
15 crypto key generate rsa usage-keys label <string> modulus <360-2048>
15 crypto key generate rsa usage-keys label <string>
15 crypto key generate rsa usage-keys
15 crypto key generate rsa general-keys
15 crypto key generate rsa
15 crypto key generate
15 crypto key zeroize rsa <string>
15 crypto key zeroize rsa
15 crypto key zeroize
15 crypto key export rsa <string> pem terminal 3des <string>
15 crypto key export rsa <string> pem terminal des
15 crypto key export rsa <string> pem url <URL>
15 crypto key import rsa <string> pem usage-keys exportable terminal <string>
15 crypto key import rsa <string> pem usage-keys exportable url <URL>
15 crypto key import rsa <string> pem usage-keys
15 crypto key import rsa <string> pem
15 crypto key pubkey-chain rsa
15 crypto key encrypt write rsa name <string> passphrase <string>
15 crypto key encrypt write rsa name <string>
15 crypto key encrypt write rsa
15 crypto key encrypt
15 crypto key decrypt write rsa name <string> passphrase <string>
15 crypto key decrypt write rsa name <string>
15 crypto key decrypt write rsa
15 crypto key decrypt
15 crypto keyring <string> vrf <string>
15 crypto keyring <string>
15 crypto xauth <interface>
15 crypto logging session
15 crypto isakmp aggressive-mode disable
15 crypto isakmp invalid-spi-recovery
15 crypto isakmp policy <1-10000>
15 crypto isakmp key <string> hostname <string> no-xauth
15 crypto isakmp key <string> hostname <string>
15 crypto isakmp key <string> address <address> <address>
15 crypto isakmp key <string> address <address>
15 crypto isakmp key <string>
15 crypto isakmp key <0-9>
15 crypto isakmp key
15 crypto isakmp key
15 crypto isakmp identity
15 crypto isakmp keepalive
15 crypto isakmp client configuration address-pool local
15 crypto isakmp client configuration group <string>
15 crypto isakmp xauth timeout
15 crypto isakmp peer hostname <string> vrf <string>
15 crypto isakmp peer hostname <string>
15 crypto isakmp peer address <address>
15 crypto isakmp nat keepalive
15 crypto isakmp profile <string>
15 crypto ipsec optional retry
15 crypto ipsec optional
15 crypto ipsec security-association lifetime seconds
15 crypto ipsec security-association lifetime seconds
15 crypto ipsec security-association lifetime kilobytes
15 crypto ipsec security-association idle-time
15 crypto ipsec security-association idle-time default
15 crypto ipsec security-association idle-time
15 crypto ipsec security-association replay disable
15 crypto ipsec security-association replay disable
15 crypto ipsec security-association replay window-size
15 crypto ipsec security-association replay window-size
15 crypto ipsec transform-set <string>
15 crypto ipsec fragmentation
15 crypto ipsec df-bit
15 crypto ipsec nat-transparency spi-matching
15 crypto ipsec nat-transparency udp-encapsulation
15 crypto ipsec profile <string>
15 crypto identity <string>
15 crypto call admission limit ike sa
15 crypto mib ipsec flowmib history tunnel size
15 crypto mib ipsec flowmib history failure size
15 crypto dynamic-map <string> <1-65535>
15 crypto dynamic-map <string>
15 crypto dynamic-map <string> <1-65535>
15 crypto map <string> <1-65535>
15 crypto map <string>
15 crypto map <string> <1-65535> ipsec-manual
15 crypto map <string> <1-65535> ipsec-isakmp dynamic <string> discover
15 crypto map <string> <1-65535> ipsec-isakmp dynamic <string>
15 crypto map <string> <1-65535> ipsec-isakmp profile <string>
15 crypto map <string> <1-65535> ipsec-isakmp
15 crypto map <string> <1-65535>
15 crypto map <string> local-address
15 crypto map <string> redundancy replay-interval inbound <0-1000> outbound <1000-100000>
15 crypto map <string> client configuration address initiate
15 crypto map <string> client authentication list
15 crypto map <string> client accounting list
15 crypto map <string> isakmp authorization list
15 crypto map <string> isakmp-profile
15 ip mobile tunnel crypto
15 snmp-server enable traps isakmp policy add
15 snmp-server enable traps isakmp policy delete
15 snmp-server enable traps isakmp tunnel start
15 snmp-server enable traps isakmp tunnel stop
15 snmp-server enable traps ipsec cryptomap add
15 snmp-server enable traps ipsec cryptomap delete
15 snmp-server enable traps ipsec cryptomap attach
15 snmp-server enable traps ipsec cryptomap detach
15 snmp-server enable traps ipsec tunnel start
15 snmp-server enable traps ipsec tunnel stop
15 snmp-server enable traps ipsec too-many-sas
15 snmp-server host <string> vrf <string> traps version 1 <string> isakmp
15 snmp-server host <string> vrf <string> traps version 1 <string> ipsec

For outputs that you want to reference frequently, like the “crypto” output above if you are in the CCIE Security Lab Exam, you can either log your output to a file through your terminal emulation software, or you can redirect the output to a file in flash, as seen below.

Router#show parser dump router router.output.dump
Router#dir flash:
Directory of flash:/

1 -rw- 29925948 <no date> c2600-adventerprisek9-mz.124-17.bin
2 -rw- 289862 Aug 29 2008 08:17:36 +00:00 crashinfo_20080829-081736
7 -rw- 55690 <no date> router.output.dump

49807356 bytes total (19478896 bytes free)

Router#more flash:router.output.dump | include ^15_(.*)eigrp
15 distance eigrp
15 eigrp router-id
15 eigrp stub
15 eigrp log-neighbor-changes
15 eigrp log-neighbor-warnings <1-65535>
15 eigrp log-neighbor-warnings
15 eigrp event-logging
15 eigrp event-log-size
15 distance eigrp
15 eigrp router-id
15 eigrp stub
15 eigrp log-neighbor-changes
15 eigrp log-neighbor-warnings <1-65535>
15 eigrp log-neighbor-warnings
15 eigrp event-logging
15 eigrp event-log-size
15 distance eigrp
15 eigrp router-id
15 eigrp stub
15 eigrp log-neighbor-changes
15 eigrp log-neighbor-warnings <1-65535>
15 eigrp log-neighbor-warnings
15 eigrp event-logging
[output omitted]
</pre>

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

May
17

Although these two articles aren't CCIE preparation related I think they both are interesting for us Cisco nerds ;)

Hacker writes rootkit for Cisco's routers

http://www.networkworld.com/news/2008/051408-hacker-writes-rootkit-for-ciscos.html?page=1

FBI Fears Chinese Hackers Have Back Door Into US Government & Military

http://www.abovetopsecret.com/forum/thread350381/pg1

Subscribe to INE Blog Updates

New Blog Posts!