Installing VMware tools on Cisco ACS

by Tony Mattke on October 21, 2013

As of ACS v5.4 Cisco has finally included VMware tools for their ADE OS. Unfortunately, when you upgrade, they do not get installed automatically as the installation is triggered during the initial install. This post is for those of us that have upgraded to version 5.4 and didn’t choose to do a fresh install.

First of all, you need to get your hands on the Root Patch. This Root Patch allows you root shell access to the ADE OS, which is just a customized version of Redhat Linux. You can get this patch from TAC by asking them nicely, or telling them you need to install VMware tools on your ACS 5.4 install. I’m sure if you’re clever you can find a copy out in the wild as well. But your mileage may vary…

Installing the ACS Root Patch

This part is pretty simple. Using the ADE OS application installer, install the package using a predefined repository…

acs/eladmino# application install RootPatch-ACS-5-4.tar.gz ftp 
Save the current ADE-OS running configuration? (yes/no) [yes] ? 
Generating configuration...
Saved the ADE-OS running configuration to startup successfully
Initiating Application installation...

Application successfully installed

Using the Root Patch

After the install, you have to logout and back in for the commands to show up in your session. Once you log back in you can run the root_enable command to set the root password. Once the password has been defined you can login using the root command.

Copyright (c) 2012 Cisco Systems, Inc. All rights Reserved

Last login: Fri Oct 18 15:34:48 2013 from
Copyright (c) 2012 Cisco Systems, Inc. All rights Reserved

acs/eladmino# root_enable
Password : 
Password Again : 

Root patch enabled

acs/eladmino# root
Enter root patch password : 
Starting root bash shell ... 
ade #

Installing VMware tools

Once you are in the root shell you can pretty much do whatever you want, including completely destroying your server. From here you simply have to navigate to the /opt/system/etc/vmware-tools-distrib/ directory and run the vmware-install script as shown below. The script should automagically configure itself and install vmware tools. Once complete exit ADE OS, and within a few momemnts VMware Tools should show as Running within the vSphere Client.

[ read more... ]

{ 1 comment }

Using Deny ACEs in your PBR ACL on your Nexus 7k

by Tony Mattke on August 19, 2013

Quite a while ago I had a need for some network duct tape… Policy Based Routing while useful should only IMHO be used as a temporary fix. But as you know, temporary things soon become part of production and they end up staying around far too long. But I digress. I had a need for some PBR, but soon found out that NX-OS had no support for deny entries in your ACL. This can pose an issue depending on the amount of destinations needed. Mine needed to match everything on the internet, minus RFC1918, and some internal VPN routes and such. Over time, I ended up having to rewrite this 100 line ACL several times, until I saw that NX-OS 6.1(3) had support for deny statements.

I was so excited, I immediately rewrote my ACL into a very svelte 20 lines including remarks. My change window came, I applied my ACL, and was faced with an error message. Luckily, I quickly figured out that we need to enable the ability to use denies.

nexus-7010(config)# hardware access-list allow deny ace

Honestly, I just wanted to get this bit of info out there as I haven’t really seen information on it. Let me know if you see any issues in your deployments.


Over the years IT professionals have sat through countless presentations, conference calls, and keynotes. We’ve been preached too, explained “the problem”, and forced to bear witness to the the future. During such events all of us have had to step up and explain that we already understand the problem, we know who your company is, and we really just want to know how your product works.

Outside of the normal annoyances, there are several words or phrases that invoke pain and disgust in our hearts, one such phrase came up today. While I won’t mention the source, or berate them anymore than they already have been. I do want to put this list out there for future reference… If I’ve forgotten something that drives you crazy, please, feel free to contact me so I can add it here.

  • Cloud — we’ve jumped the shark with Cloud years ago….
  • Gartner — No one that understands technology cares what Garner says. Period.
  • Magic Quadrant — See above.
  • Single Pane of Glass — An overly obvious marking term.
  • Next Generation — Really? Prove it.
  • Game Changer — See above.
  • Software Defined $something — Just like Cloud, we’ve driven this into the ground
  • And last, but not certainly lease… money shot.

Other things to avoid are keeping us at 30,000 feet instead of letting us get dirty, Death by PowerPoint, and circling the airport and refusing to land. And don’t forget using cliché metaphors…

Things I hate


Cisco ASA Packet Captures for Fun and Profit

by Tony Mattke on March 11, 2013

As many of you know my background isn’t in enterprise, but I currently fill that role in my $job. In order to succeed I’ve had to develop many new skills including learning Cisco Wireless, UCS, a little Fibre Channel, and of course Cisco ASA. While I have been using firewalls for many years, I’ve never used the ASA for anything more than a user firewall, or for supporting a small branch. So yes, my skills are lacking in the ASA market compared to other technologies, and when you get deep into the grind with any product you’re going to need some new tricks to aid in your troubleshooting. This is where ASA paacket captures come into place.

Define Interesting Traffic

As with any packet capture, or even log viewing the amount of noise involved generally dwarfs the data you actually want to find. In order to ease your pain Cisco has allowed us filter out packet capture using an ACL.

FW# access-list FOO line 1 extended permit ip any host 
FW# access-list FOO line 2 extended permit ip host any 

Once you have your traffic defined, you need to setup your capture. Below I’ve defined a capture named appropriately, FOO, capturing headers from our outside interface that matches our ACL with a 100,000 byte buffer. In ASA 8.0 and above you can do the same capture without the ACL using the match option, which captures traffic bi-directionally.

FW# capture FOO type raw-data access-list CAP buffer 100000 interface outside headers-only
! 8.0 and above
FW# capture FOO type raw-data match tcp any host buffer 100000 interface outside headers-only

Viewing your capture

Viewing your capture on the firewall is easy enough using the show capture command. You can do some basic filtering using the built in IOS | include / exclude as well.

FW# sh capture FOO 

1446 packets captured
1062: 10:53:32.978983 > . 2979731571:2979732951(1380) ack 3788440994 win 8204 
1063: 10:53:32.978999 > . 2979732951:2979734331(1380) ack 3788440994 win 8204 
1064: 10:53:32.979014 > P 2979734331:2979734949(618) ack 3788440994 win 8204 
1065: 10:53:32.982691 > . ack 2979734949 win 16560 
1066: 10:53:34.712441 > S 3576506984

For more detailed information you can use the detail or dump option with the show command.

While viewing the files on the firewall is handy in a pinch, it is far from your only option. You can also copy the capture off the firewall using tftp or ftp using the copy command copy /pcap capture:FOO tftp:. The firewall exports the capture in PCAP file format, which allows you to retrieve the file and open it up in Wireshark! Although if you don’t run a tftp or ftp server on your desktop, an even handier option may be to simply access the file in your web browser using the following url. https://FIREWALL_IP/capture/FOO/pcap

You need to allow http access from your workstation on the interface you’re entering

Another cool trick is setting up a circular buffer to continually watch interesting traffic. Something I’m using on one of my current projects is a capture that watches for flows that are denied via ACL.

FW# capture denied type asp-drop acl-drop buffer 4194304 circular-buffer headers-only 

Now, once you’re done tracking down what you broke, you probably want to stop the capture, and remove the files. This is done by simply issuing a no capture NAME command from the CLI.

Like I said, I’m not a firewall guru, but this can certainly go a long way to make you look like one to your systems guys when they forget to tell your their web app opens a java client that needs to communicate on TCP/9960….. Not that they’d actually do that or anything.

If any of you have any other cool tricks you can do with ASA Packet Captures please feel free to leave a comment below so I can update the article and give you credit!


Fixing iMessage on Hackintosh

by Tony Mattke on January 23, 2013

Mid December 2012 Apple shut down the Messages Beta for Lion, soon after many hackintosh users started noticing issues with signing into iMessage. At some point in time, people far smarter than me managed to patch a little used bootloader called Clover to allow us to log into iMessage, but Clover is young and still full of random issues. Honestly, it never liked the system id on my partition, so I was never able to use it. But now, it seems that someone has patched our widely used Chameleon bootloader! I’ve tested it on my own hackintosh, and many users are also reporting success.

The instructions are simple enough, and should only take you 3 minutes + a reboot to implement and test!

  1. Download the following files to your hackintosh
  2. Execute the following commands
  3. sudo mkdir /Extra/modules
    cd /Extra/modules
    sudo unzip ~/Downloads/
    sudo rm -rf __MACOSX
    sudo rm -rf ACPICodec.dylib

    If you have ACPICodec.dylib in your /Extra/modules folder, you need to delete it.

  4. Unzip the Chameleon installer, and run it — make sure you install to your boot disk
  5. Reboot, and try to login to iMessage

Hopefully this will take care of your issues. If not, it was worth a try! I highly recommend the Insanely Mac Forum for researching any issues you may be having. After all, where do you think I learned how to do this?


ASA Double Nat in 8.4+

by Tony Mattke on September 28, 2012

Recently I was faced with an issue outside my normal expertise… those of you that know me realize I am anything but a security engineer. But in reality, you must always expand your horizons. One of the projects I’m working on involves migrating between two edge networks. Obviously, for a time there has to be traffic using both networks while you migrate services from one network to the other. This creates an issue from services that may be NAT’d from the inside of the network, where as the current (read: old) default route takes them out a different connection..
In order to solve this, you need to either change the default route, which may not be possible, or start NAT’ing the source address of your traffic. It took me a bit of time to get the details worked out, so I wanted to share what I found out.

Plain Jane Static NAT

Since 8.3, NAT has changed quite a bit. The most obvious change is the use of Object groups pretty much everywhere. In some ways, this simplifies the config. In others, not so much. Basic static NAT takes the form of a single object group that defines the inside host, and the static NAT statement.

object network SERVER
  nat (OUTSIDE,INSIDE) static


The biggest thing that kept giving me issues was that I was attempting to reuse the normal static NAT config, and build a separate PAT config for the source address. Once I realized I was being a tool, the solution came rather quickly. This NAT statement is configured in the same manner as Identity NAT, used to prevent address translations to certain destinations. First you define two object groups, one for the NAT address, and one for the real inside address of the server.

object network SERVER_NAT
object network SERVER_INSIDE
nat (OUTSIDE,INSIDE) source dynamic any interface destination static SERVER_NAT SERVER_INSIDE

Next comes this slighly confusing NAT statement…

nat (OUTSIDE,INSIDE) — this is familiar, should make sense to most of us.

source dynamic any interface — this states that our source address is using dynamic NAT/PAT, the traffic could originate from anywhere, and should be NAT’d to the interface it leaves the firewall on. This is the key to our source NAT/PAT configuration…

destination static SERVER_NAT SERVER_INSIDE — finally, this just states the our destination is a static NAT statement, translating our object group SERVER_NAT, to the address in the object group SERVER_INSIDE.


So, hopefully this makes sense… if not, please remember that provides no warranties or promises and that you’re just as hopelessly screwed as I am. Thanks for stopping by!


CCIE Potential

by Tony Mattke on April 24, 2012

INE published a great info-graphic on the earning potential of Cisco’s certifications and I felt the need to share it here. It covers a range of topics from average salaries on all three tiers of proficiency, to top locations for positions, always remember that the information included is in no way meant as career advice.


QinQ: IEEE 802.1Q Tunneling

by Tony Mattke on April 19, 2012

In situations where service providers want to offer transparent LAN services that preserve a customers VLAN tags across your Layer-2 network, This amendment to the IEEE 802.1q standard allows us to use a single VLAN to transport multiple VLANS across the MAN or WAN. In doing so, we stack on an extra 802.1q tag to the customer’s traffic at the provider’s edge (PE). The original 802.1Q specification allows a single VLAN header to be inserted into an Ethernet frame. QinQ allows multiple VLAN headers to be inserted into a single frame, this is essential when implementing Metro Ethernet networks.

QinQ Configuration

First we need to ensure our transport switches can support the baby giant frames. To check the current MTU on the switch you can issue the command show system mtu and in global configuration mode, you can use system mtu 1504 to change the switches MTU to the recommended 1504 bytes..

SW1# show system mtu
System MTU size is 1500 bytes
SW1# configure terminal
SW1(config)# system mtu 1504
Changes to the System MTU will not take effect until the next reload is done.

The actual QinQ configuration takes place entirely on the transport switches, no modifications are required on the customer equipment. The first step is to configure the trunk between our two backbone switches. We’ll be using VLAN 101 for Customer-A, and 201 for Customer-B. As you will see, the configuration is rather quick and simple.

SW1(config)# interface fa1/0/48
SW1(config-if)# switchport trunk encapsulation dot1q
SW1(config-if)# switchport mode trunk
SW1(config-if)# switchport trunk allowed vlan 101,201

SW2(config)# interface fa1/0/48
SW2(config-if)# switchport trunk encapsulation dot1q
SW2(config-if)# switchport mode trunk
SW2(config-if)# switchport trunk allowed vlan 101,201

[ read more... ]