I recently upgraded a customer ASA from v8.2 to 9.0 and while doing that I found out that some (yeah!) of the static NAT translations didn´t work after the upgrade. Skilled ASA-upgraders knows that this happens a lot. That´s why we (yes I hereby include myself in the ´skilled´-group) more often than not start our post-upgrade with a ´clear configure nat´and rebuild everything from scratch (and paper notes). I did the same this time, with the only different that some services wasn´t reachable after me finishing my work.

It took me a while to find out that the common thing with the non-working translations was that they were using one of the public subnets the ISP had assigned to the customer while all translations that used another public  ip subnet worked flawlessly. I isolated the problem by changing IP of one of the nat-statements to another IP in the other range and it ofcourse worked!

So, what was this all about? I know from one of the late friday nights when I read the ‘ASA CLI configuration guide’ (it´s great, everyone should read it!) that Cisco recommends what when using multiple public ip ranges the ISP should route the secondary subnet to the ASA interface address.

But, I also know several customers that doesn´t follow these guidelines for historical reasons. Instead the ISP puts the second subnet as a secondary address on the interface facing the customer. And it has worked great, for years!

Until now. Thanks to a colleague I got aware of the fact that Cisco in version 8.4.3 made the ARP-behaviour of non-connected subnets more restricted. There was a command added ‘arp permit-nonconnected‘. This is documented here and here.

So, what is the recommendations? I recommend:

1. If possible, do not use more than one subnet range of public ip addresses. If you do and it is because of a migration-from-one-range-to-another-has-stuck-halfways, please finish the work.
2. Make sure that the ISP does not configure the ranges as secondaries (See above). If they need to change config, ask them to do it during a maintenance window and change the firewall configuration accordingly, at the same time.
3. If the ISP uses secondaries, add the command ‘arp permit-nonconnected’ to the configuration.

The picture below should be self-explaining. Click it for a larger version.

The text below is just for Google indexing purposes, please ignore.

Do you need to use the clientless SSLVPN
portal?

Anyconnect
Essentials
Licenses will be fine.
L-ASA-AC-E-55xx=

where xx is the hardware model.

Example: L-ASA-AC-E-5510= for an ASA5510.

This will give you Y concurrent any connect sessions where Y is the maximum number supported by the hardware platform. For example 250 for an ASA5510.

You must have
Anyconnect Premium licenses.
Decide how many concurrent sessions (Anyconnect + portal) you need to support.

The fixed options are 10, 25, 50, 100, 250, 500, 750, 1000, 2500, 5000 and 10000.

Note! you cannot add more licences than the hardware supports! (for example 250 for a ASA 5510).

Have you added Premium licenses to the firewall before?

Buy licenses L-ASA-SSL-xx-yy=
where xx is the current number of premium licenses in the box and yy is the number of licenses you want to have.

Example: L-ASA-SSL-100-250= to upgrade from 100 to 250 concurrent sessions.

Note! This license is the same for all hardware platforms.

Need for Advanced Endpoint Assessment?

Not sure? The answer is probably No.

Buy licenses L-ASA5500-SSLxx
where xx is the number of concurrent sessions to support.

Example: L-ASA5500-SSL10 or L-ASA5500-SSL2500.

Add ASA-ADV-END-SEC=

Need anyconnect support for mobile devices like iPhones, iPads, Android-devices?

Add L-ASA-AC-M-55xx=
where xx is the hardware model.

Example: L-ASA-AC-M-5510 for an ASA5510.

No matter if you use Premium or Essentials licensing, mobile devices will also be supported and will be included in the overall license counting of Essentials/Premium limits.

When releasing Cisco ISE as a “new ACS” questions quickly raised regarding the fact that there is no Tacacs+ support in ISE. With v1.0 of ISE Cisco said “Tacacs+ will come in a future version” but we haven´t seen it in v1.1, not in 1.1.1 and not in 1.2 either. Will it be added to v2.0? Maybe…

So, why is Tacacs+ so important? First of all we need to look at a comparison between Tacacs+ and Radius.  The similarities between the two protocols are many. Both are are authentication protocols with the purpose of validating user identity (authentication), giving differentiated access (authorisation) and logging access (accounting). However, there are also large differences between the protocols which can be read here.

Historically most AAA implementations uses Radius for end user access, remote access to networks and 802.1x while the primary purpose for Tacacs+ is for device administration. When logging into a Cisco (it must be a Cisco-device since Tacacs+ is Cisco proprietary) device Tacacs+ has additional functions that Radius lacks. The most obvious difference is the command authorization function of Tacacs+ which makes it possible for the managed Cisco-device to send each issued command  (for example ´show run´) to the authentication server (ACS) and wait for respons before allowing the command to be executed or not.

So, when migrating from ACS to ISE, Tacacs+ can no longer be used and there is no way to allow or disallow specific command on a Cisco device.

In my opinion Tacacs+ is used for device administration authentication because “we have always done it that way”. But, command authorization is rarely implemented. And in most cases when command authorization is in used, the ACS policy just saids “these users are allowed to do all commands” and “these users are not allowed to access the device at all.”.

So, what CAN we do with Radius based device administration authentication? This is possible:

• We can make each user allowed exec (CLI) access or not.
• We can give each user session a specific privilege level.
• We can do accounting to log which user accesses each device when.

Configuration of the switch

Below are the configuration changes I have made to a switch in production environment. I have removed all non-relevant configuration. The goal with the configuration is to authenticate access using Radius and having a local authentication as a fallback. This means that if the ISE is non-responsive it is possible to login with the locally created user after a short timeout.


username jimmy password 0 MyLocalPassword

A local username/password is created for fallback.

aaa new-model

This enables aaa configuration commands in the device
aaa authentication login default none

This command is important. It states that if not configured elsewhere no login is being uses. Practically this allow us to access the device from console no matter what.

aaa authentication login VTY group radius local

A new authentication list “VTY” uses radius primarily and “local” as fallback.

aaa authorization exec default none

The same for authorization. By default we don´t do it.

aaa authorization exec VTY group radius local

A new authorization list “VTY” uses radius and local.

aaa accounting exec default start-stop group radius

For each cli login (exec) we send an radius accounting packet. “start-stop” means that we also send a note when the user logs out.


radius-server host 192.168.1.106 auth-port 1645 acct-port 1646 key cisco
radius-server source-ports 1645-1646

We define the radius server and the key to use to communicate with ISE.
!

line con 0
line vty 0 15
authorization exec VTY
login authentication VTY


Specific on the vty lines (telnet/ssh access) we apply the authentication and exec authorization lists above. Note that this does not apply to con(sole) which still uses the default lists that does “none” authentication/authorization.

Configuration of Cisco ISE

Below are the steps to configure Cisco ISE. The screen dumps below are from a newly installed fresh ISE config. In case of an in-production ISE please make sure that your changes does not impact existing functionality!

First step is to configure Radius. We define a new device, gives it a name, enter its ip address and the same radius key that is defined in the device (See above). 

Next step is to create a device group. The purpose is to give all device that will use this configuration a specific attribute to use in the policy created later. By doing this we make sure that is is only devices in this device group “Managed Cisco-switch” that are allowed to use the authentication policy. We create a new device group and adds our switch to the group.

Next step is to create a policy element called “Allowed protocols”. Exec logins in cisco-devices uses the PAP/Ascii protocol and by creating a policy only allowing this protocol we minimize the risk of our policy (not yet created) conflicting with other policies.

Now is the time to create the authentication policy. This is the first step in the login authentication process and the authentication policies differentiates different login sequences. This policy called “Cisco CLI-access” simply states that”if the device is in our group ‘Managed Cisco-switch’ and the radius NAS-port is ‘Virtual’ we allow only the PAP-protocol and authenticate the login by using the Internal Users database.

The ‘Radius:NAS-Port-Type=Virtual’ means ‘only for cli login’ and is a precaution to not interfere with other authentications like 802.1x and RAS/Dialin.

Now we have configured everything that has to do with the authentication process. Next step is to configure authorization.We create 2 different authorization policy results called “Shell_priv_15″ and “Shell_priv_7″. And here is the secret behind all this: the policies sends either the Cisco AV-pair “shell:priv-lvl=15″ or “shell:priv-lvl=7″ to give different privilege level access. Also we send “Radius:Service Type=Login”.

Now we create an authorization policy putting it all together. The rule states that “if user is member of the CiscoCLIUsers-group we use the authorization profile Shell_priv_15 (and sends the radius attributes defined in that)” and the same for Lvl7CLIUsers members.

We also need to create the two different user groups and 2 users, on member of each group. Don´t forget to enter passwords for each user.

Now everything is in place and a CLI login to the switch prooves wanted functionality.


User Access Verification

sw1#sh priv
sw1#sh privilege
Current privilege level is 7
sw1#

 

So the user CLIuser1 gets privilege level 15 and user RestrictedCLIuser1 will only get privilege level 7.

Finally, how does this look like in the ISE logs? If we look into the Live Authentications log we see the that the user CLIuser1 is successfully authenticated (green line) and that the Authorization profile Shell_priv_15 was applied. The same goes for the other users login. Unfortunately not in the screen dump below, though.

Also, since we enabled radius accounting for exec on start-stop, an accounting packet is sent to ISE on every successfull login and logout of the switch CLI. This is logged and can be seen in the report “RADIUS Accounting” as seen below.

This post prooves that AAA Radius for Cisco device administration serves as a good alternative to Tacacs+. However there is one major drawback with doing what I explained above: In order to allow different Authorization profiles to access different sets of CLI commands the commands needs to be “moved” to different privilegels. In the example above, even if the RestrictedCLIUser1 gets privilege level 7, there are no command available on that level. By default there are only commands assigned to privilege level 1 (the commands available at the > prompt) and level 15 (the commands available at the # prompt). And moving commands to different privilege levels is a local configuration in each device (in comparison to Tacacs+ where we could put the ” command policy” central on the ACS”). The drawbacks with this are obvious:

• Since the configuration is local it needs to be managed on each device which is messy without some kind of management tool that makes all device´s configurations consistent.
• The commands for moving commands to privilege levels are messy and tricky to configure. This is an obvious for an upcoming post. Stay tuned!

Without any prior notice Cisco released software version 9.1 for the ASA firewall.

The only new feature in 9.1 is CX support for other X-models than 5585-X. This probably means that it very soon will be possible to run CX-functionalities in all models from 5512-X up to 5585-X. I say ´soon´because still there doesn´t seem to be any licenses for this available for purchase. I hold my breath while waiting!

This is probably the most perverted form of NAT I have ever done. <flamebait> But, it serves as a proof that with proper NAT there is no need for routing </flamebait>

Scope:

There is a Cisco ASA running code 8.3+ that divides my home network 192.168.1.0/24 from my lab networks. My home devices uses 192.168.1.1 as default gateway and has no other routes configured. Behind the Lab-firewall there is a host with dual NIC:s. The host is connected to my Lab-wirewall via a point2point-network 10.51.1.0/30 and has a default gateway pointing elsewhere.

Goal:

I want the lab-computer to reach my vSphere-server 192.168.1.112:444 and I do also want any computers on my home network to remote control the lab-computer with vnc. I do not want to add extra routes anywhere.

Solution:

object network vCenter
host 192.168.1.112
object network pod1inside
host 10.51.1.2
!
object service RDP
service tcp destination eq 3389
object service RDP_13389
service tcp destination eq 13389
!
object service VNC
service tcp destination eq 5900
object service VNC_5901
service tcp destination eq 5901
object service vSphere
service tcp destination eq 444
!
nat (pod1_151,inside168) source static pod1inside interface destination static interface vCenter service vSphere vSphere
!
nat (inside168,pod1_151) source dynamic any interface destination static interface pod1inside service VNC_5901 VNC

The above configuration makes it possible to:

• run the vSphere-client on the lab-computer and connect to 10.51.1.1:444. The source-address of the packet will be translated to the interface-address of inside168 (192.168.1.2) and the destination address will be translated to 192.168.1.112.

• run VNC viewer on any computer on the 192.168.1.0/24-network and connect to 192.168.1.2:5901. The source address of the packet will be translated to the interface address of pod1_151 (10.51.1.1), the destination address will be translated to 10.51.1.2 and the destination port will be translated from 5901 to 5900.

The long awaited 9.0 software for Cisco ASA firewall is now released and available for download from cisco.com. Here is a short list of the most obvious new features:

Scansafe integration

From now on there is built-in support for Cisco Cloud Web Security (formerly known as ScanSafe). Up until now the any support in ASA to redirect outbound web traffic to a ScanSafe-tower was to use destination NAT, which had some obvious limitations.

Now you create a policy-map that specifies interresting traffic with an ACL (which for example specified all web-traffic sourced from your internal networks) and the ASA automatically sends the traffic to Scansafe. In order to do that you have to specify a group ID as well as the hostname of one or two scansafe towers.

Together with IBFW (identity based firewall) there can be an AD-integration which gives group membership and other AD-parameters in the configuration GUI of Scansafe. This integration gives the ability to:

1. Filter outbound web traffic based on web category so that the finance-department (members of that AD-group) are allowed to access banking sites, students are allowed to access facebook but not facebook games and so on.
2. Automatically scan all web traffic to/from your organisation for viruses/malwars/trojans.
3. Automatically block traffic to the darkest corener of internet by using the bulit-in web reputation classification in Scansafe which is updated 24/7/365.

Clustering

This is probably the one single feature that is most wanted and longed for! In previous versions, the only way to load-share traffic between multiple hardwares was the “active-active”-solution that has the following limitations:

1. There can only be 2 boxes in a “cluster”.
2. They need to run multiple context mode.
3. Each context is at any given time only active in one box.

Now it is possible to group multiple (up to 8!) boxes together so that they act as one single unit with dynamic load-sharing between the boxes (in single- OR multiple-context mode!). So from now on there can be REAL clustering in ASA-firewalls. Unfortunately at the moment only for 5580 and 5585-X firewalls but hopefully this will change!

New features in mutiple context mode

Some previous limitations of running the ASA in multiple context mode has now been removed so that from now on a virtual context can do:

1. Dynamic routing with EIGRP and OSPF (there are limitations in making adjacencies between contexts communication over a shared interface because of multicast limitation in multiple context mode!).
2. VPN. There is now ipsec-support in contexts. Lan2Lan-tunnels only, no remote-access.

IPv6-features

The number of new IPv6-features in ASA 9.0 is massive! If you are interrested in this please see the release notes linked in the bottom of this post. A few examples of new features:

1. Ipv4 and ipv6 in the same acl:s/ruleset. This also includes that you can make an object “Webserver” that inclueds both the servers v4- AND v6-address in the same object and you only use the object in your acl:s.
2. NAT beween ipv4 and ipv6.
3. DHCP relay and OSPFv4.

Upgrading

The upgrade from 8.x to 9.0 includes a migration that is not reversable. Most notable the any-keyword in acl:s is replaced with “any4″ and that “any” from now on means “all v4 AND v6″. Upgrading is possible directly from any previous version without intermediate steps.

References:

The release notes for ASA version 9.0:
www.cisco.com/en/US/docs/security/asa/asa90/release/notes/asarn90.html

“I cannot connect with my Cisco IPSec VPN-client when I am behind a firewall”

“I can connect my VPN-client but can´t get any traffic thru”

“I have changed the settings on the Transport-tab and now I don´t know which settings are correct”

Have you heard them all? I have, plenty of times! In fact, IPSec can be really messy to get to work, because when it was invented there was no such thing as NAT devices and IPSec doesn´t play very well with address translations. There are workarounds. Alot of them. And that´s why it is a bit messy.

Client settings

In the client there are settings under the transport tab tha changes how the client communicates with the head end. Unfortunately, these settings are not protected which means that the end use can (and will!) changes these settings. So, what does the different settings mean?

Enable Transparent Tunneling: No

This mode is the vanilla way of IPSec by the book. The tunnel is setup by using ISAKMP (udp/500) and the actual data is sent as ESP (ip/50).

Because of the way ESP works it doesn´t work well if the client is behind a firewall or other NAT device. If outbound ISAKMP is allowed, the client can connect and authenticate. But the ESP-data will never get thru and the user will experience that the tunnel is broken even if he was able to login.

Enable Transparent Tunneling over UDP

 This is the most common way to overcome the limitations of ESP. The tunnel setup is still being done over ISAKMP (udp/500) but the actual data is encapsulated in udp-packets (udp/4500).

For this to work, the head end must be configured with ‘crypto isakmp nat-traversal‘. This command will cause the head end to tell the client during tunnel setup to send data over udp/4500 instead of ESP. Without this configured in the head end, the client will experience the same thing as when Transparent tunneling is disabled (see above) because it will still use ESP for data-transfer unless told otherwise by the head end.

Enable Transparent Tunneling over TCP

This setting is rarely being used. It was invented in the Cisco VPN3000 concentrator and is also supported in pix/ASA. By tunneling traffic over a TCP/port both the tunnel setup and the actual data is sent over that port. That means that ISAKMP (udp/500) is not being used when doing IPSec over TCP. The default port (and most common) is tcp/10000 but any port will do good. But, the port must be specified in the head end with the ‘crypto isakmp ipsec-over-tcp port 10000′ command.

Answers

So, what are the answers for the end user questions on top of this post? I would say:

Q: “I cannot connect with my Cisco IPSec VPN-client when I am behind a firewall”

A: Make sure that the firewall administrator at the current location makes sures that the following ports are opened outbound:

• udp/500 (ISAKMP)
• udp/4500 (IPSec nat-traversal)
• udp/10000 (IPSec over TCP)

Q: “I can connect my VPN-client but can´t get any traffic thru”

A: Enable transport tunneling over UDP in the Transport-tab and try again. If you can still connect but not communicate, make sure that the firewall administrator (at the site to which you are trying to connect!) enables nat-traversal with the ‘crypto isakmp nat-traversal’-command.

Q: “I have changed the settings on the Transport-tab and now I don´t know which settings are correct”

A: Duh! How would I know? Ask your firewall administrator or IT helpdesk. If you still has a copy of the original .pcf-file, try to delete your current profile in the vpn-client and import the .pcf-file again.

My recommendations

Since there are a number of ways to configure the VPN client and the central firewall, which one should we use? Which one gives us least headache? I would say that you should choose from the below, in given order:

1. Don´t. Use AnyConnect instead of the old IPSec-client. There are zillions of reasons why, but they doesn´t fit into this blog post. Anyway. Migrate to AnyConnect if possible!
2. Use Transparent Tunneling over UDP. Make sure that the central firewall is configured with NAT-traversal as explained above.
3. Use Transparent Tunneling over TCP. But don´t. There is an extra overhead in encapsulating the end user traffic in yet another layer of TCP-sessions. UDP is better. But if you want to use TCP, use port 10000 because it is already entered by default in the vpn client.
4. Use the client without transparent tunneling. You use GRE and will never get the client to work from behind a firewall.

Yesterday at the RSA Conference Cisco released a new product named ASA CX. As usual when Cisco releases information about new products you have to dig alot to see thru all marketing material and find technical details. And so is defenately the case here also.

There are a few videos recentely uploaded to Youtube by Cisco that describes the product, and a few links in the marketing material cross-referencing eachother. But not much more than that. Yet. However, this is what I have found (and what I can guess by reading between the lines):

ASA CX is Micro Application Aware. This means that it should be able to filter traffic based on Layer7-information to for example block Facebook Chat, but allow Facebook Updates. Allow Skype, but block Bittorrent. And so on…

ASA CX also saids to be web reputation aware and to be able to block 0 day malwares. Together with Identity Based Firewalling (allow/deny traffic baesd on user/group-belongings rather than just ip addresses) and URL filtering it smells alot like they have put a Cisco Ironport WSA-box inside of the ASA.

Cisco ASA CX is by Cisco Prime Security Manager which is shipped with (within!) the ASA CX, which means no more ASDM!

What confuses me most is that even though there is information on Ciscos website that ASA CX comes as 2 modules (“CX SSP-10″ and “CX SSP-20″) there is also a new product line of ASA:s visible on the product comparison chart: 5512-X, 5515-X and so on… And with yet no information available on in which models of ASA you can put the CX SSP-modules, I still cant tell what´s needed to run ASA CX. Can I upgrade my existing ASA-firewall to CX with a module? And if so, which models can be upgraded? If not, what models of ASA CX appliances are available? Does an ASA5512-X contain an XS SSP-10? And so on….

A conclusion: It´s really thrilling that the next generation of ASA Firewalls can do this granular application inspections that hasn´t been possible yet. And together with functions available in the WSA, ASA CX can be a really potent threat to it competitors! ASA is no longer a packet filtering firewall!

Update!

According to a anonymous but normally highly trustworthy source (who prefer to call himself Deep Throat ), the CX will at first be a module available only for the high-end 5585-X ASA:s. At a next step the CX will be a software function available in the newly released 5505-X ASA-models. There will probably not be any CX-support in the legacy ASA:s.

Or – ASA Lan2Lan-VPN for dummies.

I often get questions related to Lan2Lan-tunnels in ASA. This post serves as a cheat-sheet for different software versions.

Pix v6.x

isakmp enable outside
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 1
isakmp policy 1 lifetime 86400

isakmp key cisco123 address 5.6.7.8 netmask 255.255.255.255

access-list 100 permit ip 10.0.X.0 255.255.255.0 10.0.Y.0 255.255.255.0
crypto ipsec transform-set MYTSET esp-des esp-md5-hmac

crypto map CMAP_OUTSIDE 10 ipsec-isakmp
crypto map CMAP_OUTSIDE match address 100
crypto map CMAP_OUTSIDE set peer 5.6.7.8
crypto map CMAP_OUTSIDE interface outside

access-list nonat_inside permit ip 10.0.X.0 255.255.255.0 10.0.Y.0 255.255.255.0
nat (inside) 0 access-list nonat_inside

sysopt connection permit-ipsec

Pix/ASA v7.0 – 8.2

isakmp enable outside
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 1
isakmp policy 1 lifetime 86400

tunnel-group 5.6.7.8 type ipsec-l2l
tunnel-group 5.6.7.8 ipsec-attributes
pre-shared-key cisco123

access-list VPN permit ip 10.0.X.0 255.255.255.0 10.0.Y.0 255.255.255.0

crypto ipsec transform-set MYTSET esp-des esp-md5-hmac

crypto map CMAP_OUTSIDE 10 ipsec-isakmp
crypto map CMAP_OUTSIDE 10 set transform-set MYTSET
crypto map CMAP_OUTSIDE 10 match address VPN
crypto map CMAP_OUTSIDE 10 set peer 5.6.7.8
crypto map CMAP_OUTSIDE interface outside

access-list nonat_inside permit ip 10.0.X.0 255.255.255.0 10.0.Y.0 255.255.255.0
nat (inside) 0 access-list nonat_inside

ASA v8.3+

crypto ikev1 enable outside
crypto ikev1 policy 1
authentication pre-share
encryption des
hash md5
group 1
lifetime 86400

tunnel-group 5.6.7.8 type ipsec-l2l
tunnel-group 5.6.7.8 ipsec-attributes
ikev1 pre-shared-key cisco123

access-list VPN permit ip 10.0.X.0 255.255.255.0 10.0.Y.0 255.255.255.0

crypto ipsec ikev1 transform-set MYTSET esp-des esp-md5-hmac

crypto map CMAP_OUTSIDE 10 ipsec-isakmp
crypto map CMAP_OUTSIDE 10 set ikev1 transform-set MYTSET
crypto map CMAP_OUTSIDE 10 match address VPN
crypto map CMAP_OUTSIDE 10 set peer 5.6.7.8
crypto map CMAP_OUTSIDE interface outside

object network MY-LAN
subnet 10.0.X.0 255.255.255.0
object network HIS-LAN
subnet 10.0.Y.0 255.255.255.0
nat (inside,outside) source static MY-LAN MY-LAN destination static HIS-LAN HIS-LAN