Jun
05

Well, we had all heard the rumors that it was coming down the line, and today Cisco decided to make it official just ahead of Cisco Live. Something very interesting thing about this update -no doubt as a result of really listening to the community's voice in regards to the things that threaten the enterprise most these days- is that they've added a heavy emphasis on Bring Your Own Device (BYOD) over wireless threats. With the addition of a Wireless Lan Controller (WLC) and at least a single AP, along with the Identity Services Engine (ISE). For those of you who may not be familiar with the ISE, this is basically an evolution of a few devices combined into one - it is sort of a mix of the ACS, NAC Appliance and NAC Profiler. However, it is NOT a replacement for the ACS, namely because it does not do TACACS+, instead only supporting RADIUS for 802.1x and NAC. This is the reason that Cisco decided to leave ACS server in there - but upgrading it to v5.x (most likely 5.3). Also, if you happen to not have any experience with wireless technologies in general - you're in luck! INE is releasing our 20-hour CCNA Wireless class later today, which covers Lightweight Access Points (LWAP) being controlled by WLCs, and those WLCs being controlled by higher-up Wireless Control System (WCS). In fact, since I've mentioned the WCS, it's quite interesting that Cisco (in sort of a nonchalant way) mentions that the ASA firewalls may be configured by "Cisco Prime Tools". If you aren't familiar with Cisco Prime, it is basically the new branding of Cisco's network management as a whole. LMS would now fall under Prime, something called Prime NCS (evolution of Cisco's WCS), and Prime Tools fall under the new Prime branding.

There's also a smidge of Voice device authentication as well, though it doesn't even begin to really touch on Unified Communications security - something I still think will largely be addressed in the next CCIE Voice update. Basically they have a 7900 phone (probably 7965) and you do NOT have to configure the Unified Communications Manager (UCM) server to get it to work, you only have to dot1x authenticate it onto the wired network. Basically setup the ISE or ACS to auth it and interact with the actual phone display to input your credentials. Don't be concerned - it's nothing difficult at all.

Cisco also (finally) introduces their IronPort acquisition to the exam, by way of the S-series Web Security Appliance (WSA). This device goes way beyond days of old where you blocked or allowed certain websites, but rather digs deep into the functionality of websites and web-based applications and provides 'acceptable use enforcement' of these sites or webapps. Take for example Facebook. Many (if not most) companies these days have a social presence and use Facebook as a tool to conduct business, but that doesn't mean they want their users surfing FB all day. The WSA allows strategic enforcement of what is and is not allowed to occur via these type web sites. It also blocks against threats such as malware.

They mention simply including "VPN Client Software" which will no doubt be the Cisco Secure Services Client v5 installed on one or possibly more Windows 7 virtual desktops placed around the topology. This would make sense for both wired and wireless 802.1x authentication with the ACS/ISE. Something we also go into in the new 20-hour CCNA Wireless class I just recorded a few weeks back. Question is whether AnyConnect Secure Mobility Client will also be tested. It's not in there per-se, but that doesn't mean it isn't possible.

The addition of at least one 2911 ISR-G2 only makes sense, as IOS version 15.2 can't be run on an older ISRs (making me wonder why the inclusion of the older ISR is even there, save maybe that there are far more deployed currently).

Links to both the new v4 blueprint and v4 hardware/software equipment list, as well as a more detailed checklist for studying:

CCIE Security v4 Blueprint

CCIE Security v4 Equipment List

CCIE Security v4 Checklist

There are obviously still a lot of questions that need to be answered by Cisco to have a complete and full picture of this new version of the prestigious CCIE Security exam, and those will no doubt be addressed during the 8-hour seminar this Sunday at Cisco Live in San Diego. I should note that this 8-hour session is an additional charge ($799) on top of your normal admittance to the convention - it is not considered a "breakout session", all of which come included with your convention pass. Some obvious questions might be:

  • Will we need to know how to configure ASA via Prime Tools, or is that simply another option?
  • How many Windows 7 desktops will there be, and will we be using AnyConnect NAM on them or something like CSSC?
  • Will there be both ASA and ASA-x versions? And if so, what would be the reason? (ASA-X series runs 8.6, whereas ASA only goes up to 8.4, amongst other things
  • And many others we'll come up with and have asked and answered

You can be sure that INE will be there, tweeting and live-blogging from the event.
Follow me and stay updated throughout the conference!

Aug
25

The first portion of INE's new CCIE Security Advanced Technologies Class for the 3.0 blueprint is now available in both streaming and download formats.  Subscribers to the All Access Pass already have access to this new course, and can upgrade to the download version for $159.  Non-subscribers can purchase the standalone download for $299, or subscribe to the AAP for just $159 per month.  Customers who have access to previous versions of the CCIE Security ATC will get access to the new streaming version at no extra charge.

The current release of the class contains the first 18 hours of videos.  New videos will be posted incrementally over the next few weeks, to bring the final runtime somewhere between 40 and 60 hours.  Specifically the following topics are covered in this first portion of the release:

  • 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
  • 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
  • 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
Aug
09

INE is proud to announce the upcoming release of our new CCIE Security Advanced Technologies Class and CCIE Security 5-Day Bootcamp. The 5-Day Bootcamp will be available in streaming and download format starting this weekend, followed shortly by the Advanced Technologies class. Both of these video series are included with the All Access Pass subscriptions, or can be purchased as standalone downloads.  Samples of both classes are available below.

CCIE Security 5-Day Bootcamp
IOS Zone Based Policy  Firewall (ZBPF)

CCIE Security Advanced Technologies Class
ASA Active/Active Failover

Nov
11

Change is in the air. I've noticed that over the last several weeks, we've had at least five security CCIE candidates pass who used INE's security products as part of their study plan. What these students have done is use a combination of our version 3 and version 5 products. Congratulations to all those who passed!

The rumor on the street is, that "IF" there were issues in the past with Cisco’s security lab, whether they were Java issues, or wording issues, etc. it seems that well-prepared candidates can now, based on results, pass this exam.  Better yet, with the update of our Vol 1 products, studying will be easier than ever.

As Brian mentioned, the roll-out of our updated volume 1 products is underway. Marvin and I would like to thank a handful of beta testers, who have done an outstanding job testing a few of our latest modules. Thank you very much for your assistance!

So you might ask, what's new and exciting about the updates for security volume 1? I'm glad you asked!

Each of the new modules in volume 1 matches up identically with the sections from the current blueprint from Cisco. This means if you just want to focus on VPN technology, you can go to section 3 and have the entire VPN section to work with.  The same is true for ASA (module 1), IOS firewall (module 2) and the rest of the sections.

The ASA module is now complete and will be posted to the member’s area this afternoon, along with the startup configuration files for all of the individual racks.  The IOS firewall module, which I know sounds like a piece of hardware, (forgive my chuckle), is finishing beta testing today and will be posted in the members area shortly. As the other modules complete beta testing they will be posted to the members area, and will begin shipping the week of November 23.

Thank you, and good luck with your studies.

Sep
25

After returning from vacation, Bob (the optimistic firewall technician) decided that he wanted to take some time and get a little bit more familiar with firewall configuration. He was able to get permission to use some spare equipment for practice.

marvin_9-25[1]

 

He started with a basic configuration on the firewall:

hostname INEASA1
password cisco
enable password cisco

interface e0/1
nameif inside
no shut
ip address 172.16.16.10 255.255.255.0
security-level 90

interface e0/0
nameif outside
ip address 136.1.122.10 255.255.255.0
security-level 10
no shut

Bob verified that he could ping both R1 and his PC from the Firewall. Now, he wants to configure the firewall to allow telnet from his PC. He remembers that there was some additional configuration that needed to be done on the firewall to allow this to work, but doesn't remember exactly what is needed. Since his PC isn't connected to the internet, he is not able to access the online documentation.

What additional configuration will allow Bob to telnet to the firewall from his PC?

There is more than one possible solution for this challenge. Feel free to post your proposed answer in the comments section. We will try to keep comments hidden from public view, so that the fun isn't spoiled for others.

____

OK, so let's look at the problem here. The PC is on the outside of the firewall, and according to multiple responses, you can't telnet to the outside interface. (or can you?)

A few helpful hints when studying for the CCIE lab.

1. Don't be afraid to go to the documentation, even for topics you think you know.
2 Re-read the question, to see just what you are asked to do and what your restrictions are.

So, where does the confusion about being able to telnet to the firewall come from? Perhaps it comes from trying in earlier versions, perhaps some confusion about what the documentation says, or perhaps someone read somewhere in the past that it just wouldn't work.

Let's start by carefully re-reading the documentation. ASA - Config guide - system administration - managing system access - allowing telnet

This section states:

"...The security appliance allows Telnet connections to the security appliance for management purposes. You cannot use Telnet to the lowest security interface unless you use Telnet inside an IPSec tunnel. ..."

So, it doesn't explicitly mention the outside, it mentions the "lowest security interface". In most cases that is the outside, but not always.

A few "solutions"

1. Configure the switch so that Bob's PC is on VLAN 121 instead of VLAN 122, configure the firewall to allow telnet on the inside interface. (Technically would meet requirements, but not much of a challenge.)

2. Change the security levels for the interfaces, making them the same or making the outside higher.

3. Add another interface with a lower security level

int eth0/1.1
vlan 123
nameif DMZ
sec 9

4. Configure a VPN for the firewall, so that the telnet traffic to the lower security (outside) interface is encrypted and therefore allowed.

5. Configure the firewall to allow transit traffic through to R1. Telnet to R1, and then Telnet to the ASA from R1, after configuring the ASA to allow telnet on the inside interface.

Sep
14

It was a dark, cold night in late December, and Bob, (the optimistic firewall technician), had a single ASA to deploy before going home for the holidays.  The requirements for the firewall were simple.   Bob read them slowly as follows:

  1. R1 should be able to ping the server "Radio.INE.com" by name.
  2. PC should be able to ping the server "Radio.INE.com" by name.

Bob also read the background information to see if this was something he could finish before leaving the office.   Bob read the following:

DNS Server is mapping radio.ine.com to the global address of 136.1.122.100
All devices have appropriate routes in place.
R1 and the PC are both configured to use the DNS server at 136.1.122.2
DNS Server, PC, R1  and supporting L2 switchports for the ASA are configured correctly.

Bob also looked at the diagram:

Bob's Quick Installation Gone Wrong

Bob put the following together in notepad, and then quickly pasted it into the ASA using Secure CRT:

!************ begin ASA configuration ************

enable

conf  t
clear config all

no nat-control
hostname ASA1
interface Ethernet0/0
nameif outside
ip address 136.1.122.10 255.255.255.0
interface Ethernet0/1
nameif inside
ip address 172.16.16.10 255.255.255.0
interface Ethernet0/2
nameif dmz
ip address 10.0.0.10 255.255.255.0
nat (inside) 1 172.16.16.0 255.255.255.0
nat (dmz) 1 10.0.0.0 255.255.255.0
global (outside) 1 interface
access-list outside permit tcp any host 136.1.122.100 eq www
access-list outside permit icmp any host 136.1.122.100 echo
access-group outside in interface outside
static (dmz,outside) 136.1.122.100 10.0.0.100

wr

!************end ASA configuration*************

After waiting a few moments, Bob went to R1, issued the following command and hoped for the best:

Ping radio.INE.com

The ping failed.    He tried the same ping from the PC which also failed.    As much as Bob “hoped” it would work, it didn’t, and Bob secretly wished he had the skills and knowledge of a Security CCIE that would allow him to quickly solve the configuration problem so he could go home for the holidays.

My fellow CCIE bloggers and INE fans, your mission, should you choose to accept it, is to identify the missing and/or incorrect elements that need to be in place for successful pings to radio.ine.com from the PC and R1.

There is more than 1 way to solve this, and there are between 5 and 7 corrections that need to take place.

Will you assist BOB?

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.

Apr
19

Modular Policy Framework (MPF) configuration defines set of rules for applying firewall features, such as traffic inspection, QoS etc. to the traffic transiting the firewall. MPF has many similarities to MQC (Modular QoS CLI) syntax found in Cisco IOS, but there are some major differences in the flow of operations, even though many commands look the same. The following post assumes basic understanding of ASA firewall and its configuration. It covers the basic logic of the MPF, but does not go over all firewall features in depth.

Traffic Flow through the Firewall

ASA is a complicated piece of hardware and software, just like any stateful firewall. However, for the purpose of understanding the MPF it is enough to use the following simplified packet flow checklist:

  1. See if packet matches a flow in the connection table if so, skip to (4). This means packets matching existing states bypass the ACL checks
  2. Find egress interface, drop packet if egress interface cannot be found. Two options:
    1. Packet’s destination address matches existing XLATE state or STATIC NAT statement. This is common when you use outside NAT. Egress interface is determined from the NAT entry.
    2. Perform route lookup on the destination IP address to find egress interface
  3. Match input access-list on the ingress interface. Use the ORIGINAL destination IP address, not the untranslated IP for matching
  4. Match flow against input QoS policy (interface or global policy, where interface policy takes precedence)
  5. Apply source NAT if XLATE state does not exist and there is matching NAT rule. Use the following order of operations:
    1. NAT exemption, configuration using the command nat (interface) 0 access-list
    2. First matching STATIC NAT or PAT, with NAT taking precedence. If multiple entries match the packet, select the first one.
    3. Dynamic NAT entries configured using the command nat (interface) [ID] access-list
    4. Dynamic NAT entries configured using the command nat (interface) [ID] [network] [mask]. If [ID]=0 then identity XLATEs are created
  6. Apply egress QoS policy (output policing, interface or global)
  7. Create or update flow information
  8. Lookup output egress interface in routing table based on destination IP. Find out the next-hop, which should be on the SAME interface as XLATE points to, if XLATE/STATIC was used at step (2). This route should not necessarily be the LONGEST match, just any matching route out of selected interface.

It is important to notice two important things: firstly, the addresses you should use in the access-lists are supposed to be pre-NAT addresses or in other words just as the packet originator sees them. Secondly, pay attention to the concept of XLATE-based routing that ASA uses. This concept requires special attention.
What is the point of pinning an egress interface to a NAT entry? The reason being the fact that if there exists an XLATE entry, then more likely there are traffic flows using it. Therefore it is desirable pinning traffic to the same interface that was used for XLATE creation – otherwise traffic may match different NAT rule and the connection will be broken. This is why the firewall attempts finding the egress interface using the XLATE first. However, what happens if the route has flapped and the untranslated address is now reachable via a different interface? The firewall will still perform a route lookup using all routes that are bound to the original interface and try finding a match. If a match is found, it is used to find out the next-hop and route packet out. If not, the packet is dropped. Look at the following configuration sample:

static (outside,inside) 180.9.59.1 180.9.1.1
!
route outside 0.0.0.0 0.0.0.0 180.9.29.2 1
route DMZ 180.9.1.1 255.255.255.255 192.10.9.254

Here packets going from “inside” to “outside” toward the IP address 180.9.59.1 are destination untranslated to the IP address 180.9.1.1. This IP is statically routed over the DMZ interface, but the firewall will only check the routes bound to the “outside” interface and use the default route to route the packet to 180.9.1.1. In this situation, even though the specific static route is not correct, the NAT-bound egress interface decision allows traffic to flow correctly.

Traffic Classification

Every MPF rule has a scope - subset of traffic that the rule applies to - and action - feature or a set of features triggered by this rule. In ASA firewall, L3/L4 class-maps are used to specify the traffic for a rule. The following is the list of the mot common classification criteria:

  • Access-List. Most typical and very flexible criterion, allows matching based source/destination IP addresses, port numbers, protocols and so on – everything you can put in an ACL. Example:
    access-list BGP permit tcp host 150.1.1.1 any eq bgp
    access-list BGP permit tcp any eq bgp host 150.1.1.1
    !
    class-map BGP
    match access-group BGP
  • Port numbers/range. Without configuring an access-list, you can specify TCP/UDP port numbers to be matched by the class map, such as follows:
    class-map PORTS
    match port tcp range 100 200
  • Tunnel Group name. Allows matching the traffic for a particular tunnel group in the firewall. The firewall will dynamically track VPN tunnels created for this group and classify traffic accordingly.
    class-map TUNNEL_GROUP
    match tunnel-group TEST

    In addition to specifying the match tunnel-group criterion, you can also configure one additional match statement. You are allowed any additional criterion with except to match any or match access-list or match default-inspection-traffic. For example the following configuration is supposed to matchVoIP traffic within the VPN tunnel, provided that VoIP packets are marked with DSCP value of EF.

    class-map VPN_VOICE
    match tunnel-group TEST
    match dscp ef
  • Per-flow classification criterion configured using the match flow ip destination-address. This one could be used only along with the match tunnel-group command. When configured, it tracks every VPN connection separately and applies the configured action per-flow, not to all VPN traffic at the same time. This is particularly useful for Remote-Access VPN connections, where multiple users connection to the firewall unit. Notice that you can apply the QoS policing feature only per-flow, when classifying based on tunnel group names. Example:
    class-map VPN_FLOWS
    match tunnel-group TEST
    match flow ip destination-address
  • Matching the default classification traffic. This is special “intelligent” type of classification used exclusively with inspect action. It matches traffic on the default port numbers for ALL available inspection engines. For example it will match FTP traffic on port 21, HTTP on port 80, DNS on port 53 and so on. As mentioned, the only supported feature with this classification type is traffic inspection.
  • Other classification criteria such as match dscp and match rtp. Those allow matching based on the DSCP value in IP packet headers and matching based on RTP port range.

    As you noticed, a typical class map will only support ONE match command. The only exception is the use of match tunnel-group along with some other match commands.

Applying Features in Policy Maps
After you defined traffic classes, you may configure MPF rules using regular policy-map. We call them regular, as there are special inspection policy maps, used to define inspection settings and parameers. Regular policy maps attach actions to L3/L4 classes using the following syntax:

policy-map <NAME>
class <CLASS1>
<feature1>
class <CLASS2>
<feature2>

The list of the applicable firewall features follows:

  1. QoS input policing. Applies to traffic entering the firewall, enforces traffic rate. Configured using the command police input| under the policy-map.
  2. TCP normalization. TCP and UDP connection limits and timeouts, and TCP sequence number randomization. Performs TCP connection modification and monitoring to enforce security settings. Configured using the command set connection and a pre-configured tcp-map with the advanced TCP parameters.
  3. CSC (if installed). Content security.
  4. Application inspection (multiple types). The core of the stateful firewall. Parses traffic streams and detects application protocols and their commands. Allows enforcing per-application security policies. The command to apply inspection is inspect {protocol-name}. Could be fine-tuned using inspection policy-maps.
  5. IPS (if installed). Intrusion prevention – allows the firewall to work as an inline IPS.
  6. QoS output policing. Applies to traffic leaving the firewall, enforces specified rate. The command is police output
  7. QoS interface priority queue. Services traffic using the interface-level low-latency queue. Configured using the command priority. Could not be applied along with policing feature.
  8. QoS traffic shaping, hierarchical priority queue. Mutually exclusive with any other interface-level QoS features. Traffic shaping could be only applied under class-default

There could be a situation when a packet/flow matches multiple classes within the same policy-map. For example, with the following configuration

class-map FTP
match port tcp eq 21
!
access-list TCP permit tcp any any
!
class TCP
match access-list TCP
!
policy-map
class default-inspection-traffic
inspect ftp
class FTP
set connection conn-max 100
class TCP
set connection conn-max 200
police input 150000

FTP packets would match all three classes at the same time. The question is: what action should the firewall apply to this flow? The rule of thumb to resolve conflicts in situations like that is as follows:

  1. For a given feature type, the flow can match only one class, based on the order the classes are configure in the policy map. In our example, the TCP connection limits are set for classes “FTP” and “TCP”, both matched by the flow in question. Since “FTP” precedes “TCP” the TCP connection limit is set based on “FTP” class.
  2. If the packet flow matches multiple classes with different feature types (e.g. QoS and inspection), then feature actions from all classes are combined provided that they are not conflicting. In our example, FTP flow will be inspected, limited to 100 connections and policed ingress to 150Kbps.

The next question is: if the multiple features are combined together, what is the order they are applied to the flow? It does not depend on the order of the class-map within the policy-map. The actions are applied in sequence, in the same order they are presented in the list above. In our example, the flow is first policed, then normalized and then inspected. Notice that some features may drop packets (such as policing) or modify the traffic contents (e.g. TCP normalization or inspection).

Levels and Directions

Policy map could be applied globally or per interface. There could be only one global policy map and one policy-map applied per interface. The question is: how those maps are combined to build the resulting set of MPF rules? When traffic goes across the firewall, the system determines the ingress and egress interfaces for the flow based on the routing table and xlate entries. The system builds the list of classes matched by the flow based on the feature direction for every class configured under the policy-maps. Here is the table from the Doc CD:

Feature Interface-Level Direction Global Policy Direction
Inspection Bidirectional Ingress
CSC Bidirectional Ingress
IPS Bidirectional Ingress
QoS Input Policing Ingress Ingress
QoS Output Policing Egress Egress
QoS Interface-Level PQ Egress Egress
QoS Shaping, Hierarchical PQ Egress N/A
TCP Normalization, Connection Limits, ISN randomization Bidirectional Ingress

How to read this table? Let’s take the TCP Normalization feature for example. Suppose it is configured at the interface level. Then, based on its bi-directional behavior, packets entering and leaving the interface will be subject to normalization process, provided that they match the respective class-map. Take another example. If you have configured FTP traffic inspection at the interface level like this:

access-list FTP_FROM_INSIDE
permit tcp 10.0.0.0 255.255.255.0 any eq 21
!
class-map FTP_FROM_INSIDE
match access-list FTP
!
policy-map INSPECTION
class FTP_FROM_INSIDE
set connection max-conn 100
inspect ftp

Then both features apply only to FTP traffic going from the inside network 10.0.0.0/24 to the outside on port 21. The traffic to the inside network on port 21 is not inspected nor limited, even though features are bi-directional, as it does not match the access-list. To inspect traffic bi-directionally you need the access-list

access-list FTP_FROM_INSIDE
permit tcp 10.0.0.0 255.255.255.0 any eq 21
permit tcp any 10.0.0.0 255.255.255 eq 21

OK, that looks reasonable enough. Now what should the firewall do if a packet/flow matches multiple classes in level policy maps applied at different levels (i.e. interface and global)? Here is how the conflicts are resolved:

  1. If there is a feature defined in the interface-level policy map and global policy map, and the flow matches both classes, the interface-level settings take precedence. For example, if the interface-level class-map FTP sets connection-limit to 100 and the global policy set the limit to 200, the resulting limit for FTP traffic is 100.
  2. If the flow matches classes at the interface-level and global policy-maps and the classes have different features configured (e.g. inspect and policing) then actions are combined. The order that the features are applied is per the list provided above.
  3. If the flow matches classes both at ingress and egress interfaces, the resulting effect depends on the type of traffic. Traffic classified “statefully”, such as TCP and UDP flows and ICMP, when ICMP inspection is enabled, triggers the same feature in different policy-maps only once. For example, if the flow enters the firewall and triggers the inspection feature in the ingress interface-level policy-map, the firewall will store this event in the state table. No further attempts to perform traffic inspection or normalization are made for this flow, even if it matches the egress interface policy. Moreover, the returning packets for the flow are not matched against the “flow-aware” features ingress on the returning interface. This is the direct consequence of the firewall stateful behavior. The list of “flow-aware” features includes: application inspection, CSC/IPS, TCP normalization and connection limiting.

What if the packet stream is not treated by the firewall as a single flow? For example, imagine a stream of ICMP packets when ICMP inspection is disabled. In this case, bidirectional features on ingress and egress interfaces will apply twice. Moreover, the returning packets will also be subject to feature actions, such as IPS checks. This behavior is also true with any flow unaware feature, such as QoS policing.

Feature Incompatibilities

As you remember, you can apply multiple actions under the same class. Some actions just can’t go together. Here is the list of the limitations:

  1. You can’t combine policing and interface-level priority queuing for the same class.
  2. You can’t configure shaping in global policy map.
  3. You can only shape ALL traffic leaving the interface, i.e. you can only shape under class-default.
  4. You cannot configure two inspect actions under the same class with except to default-inspection-traffic class.

What if traffic flow matches multiple classes and those classes define different protocol inspection actions? For example, what if the interface policy has two classes configured like the following:

class-map FTP
match port tcp eq 21
class-map HTTP
match port tcp eq 21
policy-map TEST
class FTP
inspect ftp
class HTTP
inspect http

Then the FTP flow will match both classes. However, one applies FTP inspection and another HTTP inspection. To resolve such conflicts, the firewall uses the list of application priorities (from the DocCD):

  1. CTIQBE
  2. DNS
  3. FTP
  4. GTP
  5. H323
  6. HTTP
  7. ICMP
  8. ICMP error
  9. ILS
  10. MGCP
  11. NetBIOS
  12. PPTP
  13. Sun RPC
  14. RSH
  15. RTSP
  16. SIP
  17. Skinny
  18. SMTP
  19. SNMP
  20. SQL*Net
  21. TFTP
  22. XDMCP
  23. DCERPC
  24. Instant Messaging

Application priority decreases in descending order, with CTIQBE inspection having highest priority. The inspection action with higher priority will be preferred in case of conflict. In the example described above, FTP is more preferred than HTTP, and thus traffic is inspected for FTP protocol.

Summary

As you can see, ASA firewall system implements sophisticated logic for traffic matching and feature application. This is the direct result of combining multiple features for the same set of traffic using the class->action based syntax. Right now the semantic is not very transparent, and it might take time to understand a particular configuration. Here is the list of basic points about MPF:

  1. Service policies could be applied globally or per-interface.
  2. A packet flow can match multiple classes.
  3. In case if two ore more classes specify the same feature, firewall applies the deterministic procedure to resolve the conflict.
  4. In the classes specify different features, they are combined, provided that the features could be used together.
  5. Many firewall features are aware of stateful traffic flows.
  6. The order that the features are applied is fixed and does not depend on the order of classes in the policy-maps.

Subscribe to INE Blog Updates

New Blog Posts!