To reset a Cisco router to factory default (removing the startup configuration file), perform these steps:

1.	To erase the configuration file, issue the erase nvram: command.

Reload the router by issuing the reload command. 2. If this does not solve the problem, attempt to break into ROM Monitor (ROMmon) by issuing the break sequence (usually Ctrl and break from the Hyperterminal) from a console connection.

Refer to:

Cisco Standard Break Key Combinations

You should see this ROMmon prompt:

rommon 1>

3. Change the configure register value to ignore the startup configuration by issuing the confreg command, as shown in this example:

rommon 2> confreg 0x2142

4. To reload the router, issue the reset command, as shown in this example:

rommon 3> reset

5. After the router boots, issue the enable command at the Router > prompt.

The prompt changes to Router#, indicating that the router is now in privileged mode.

6. To enter config mode, issue the config terminal command.

You should now see a Router(config)# prompt.

7. To change the configure register to recognize the startup configuration, issue the config-register command, as shown in this example:

Router (config)# config-register 0x2102

To break out of configuration mode, press Cntl and Z.

To save the blank configuration, issue the copy-running config-startup config command.

notes

Cisco PIX/ASA Causes SMTP Banner Corruption

November 8th, 2009 Aaron Leave a comment Go to comments

Traffic inspection rules on a Cisco PIX or ASA firewall will sometimes cause the SMTP banner to appear corrupted.

When testing access to your mail server from outside, you may notice that the SMTP banner looks like this:

This is just a symptom of the problem, which is that the SMTP traffic inspection rule is interfering with the SMTP data stream.  Another symptom would be to see email messages destined for this server seemingly stuck in the SMTP queue on a server outside the network.  This can ultimately cause delayed and undeliverable mail, especially for larger messages, such as those with attachments.

The resolution for this problem is to disable the traffic inspection rule for SMTP/ESMTP on the Cisco PIX or ASA firewall.

On a PIX, this can be done from the command-line using the “no fixup protocol SMTP 25” command.  It can also be disabled from the PIX Device Manager (PDM).

On an ASA, it’s a little different.  From the command line (assuming your policy map is named “global_policy” and your class is named “inspection_default”):

CiscoASA(config)#policy-map global_policy
CiscoASA(config-pmap)#class inspection_default
CiscoASA(config-pmap-c)#no inspect esmtp 

From the Adaptive Security Device Manager (ASDM):

1.       Go to Security Policy –> Open the inspection rule:

2.       Go to the Rule Actions tab and uncheck the box next to ‘ESMTP’

3.       Test from outside the PIX/ASA again by telnetting to port 25; your SMTP banner should now look like this (I have masked the name of the server for privacy).

That’s it.  I have made it standard practice to just disable this inspection rule on all Cisco ASA firewalls that I deploy to avoid problems.

Notes

Figure 2-13 shows the use of source and destination ports. The host on the 10.1.2.0/24 network accesses a single host for both web services and Telnet services. When the host accesses the server for web services, the local address is translated to 209.165.202.129. When the host accesses the same server for Telnet services, the local address is translated to 209.165.202.130.

Figure 2-13 Policy NAT with Different Destination Ports

The syntax for this configuration example follows:

access-list WEB permit tcp 10.1.2.0 255.255.255.0 209.165.201.11 255.255.255.255 eq 80

access-list TELNET permit tcp 10.1.2.0 255.255.255.0 209.165.201.11 255.255.255.255 eq 23

nat (inside) 1 access-list WEB

global (outside) 1 209.165.202.129 255.255.255.255

nat (inside) 2 access-list TELNET

global (outside) 2 209.165.202.130 255.255.255.255

Limitations

The following configuration limitations apply to policy NAT:

•Access lists must contain permit statements only. Access lists for policy NAT cannot contain deny statements.

•An access list must be used only once with the nat command. For example, the following configuration would produce an error:

nat (inside) 1 access-list mylist-A

nat (inside) 2 access-list mylist-A

Whereas, the following configuration would not produce an error:

nat (inside) 1 access-list mylist-A

nat (inside) 2 access-list mylist-B

•Use an access list only once between the nat and static commands.

•A global address cannot be used concurrently for NAT and PAT.

•static commands are matched and executed before nat commands.

•Policy NAT does not support SQL*Net, which is supported by regular NAT.

Notes

Step 1. Verify that the Date, Time, and Time Zone Values are Accurate

ASDM Procedure

1. Click Configuration, and then click Device Setup.

2. Expand System Time, and choose Clock.

3. Verify that the information listed is accurate.

   The values for Date, Time, and Time Zone must be accurate in order for proper certificate validation to occur.

   

Command Line Example

ciscoasa
ciscoasa#show clock 11:02:20.244 UTC Thu Jul 19 2007 ciscoasa#

Step 2. Generate a Certificate Signing Request

A certificate signing request (CSR) is required in order for the 3rd party CA to issue an identity certificate. The CSR contains your ASA's distinguished name (DN) string along with the ASA's generated public key. The ASA uses the generated private key to digitally sign the CSR.

ASDM Procedure

1. Click Configuration, and then click Device Management.

2. Expand Certificate Management, and choose Identity Certificates.

3. Click Add.

   

4. Click the Add a new identity certificate radio button.

5. For the Key Pair, click New.

   

6. Click the Enter new key pair name radio button. You should distinctly identify the key pair name for recognition purposes.

7. Click Generate Now.

   The key pair should now be created.

8. To define the Certificate Subject DN, click Select, and configure the attributes listed in this table:

   Table 4.1: DN Attributes

   Attribute	Description
   CN	FQDN (Full Qualified Domain Name) that will be used for connections to your firewall. EX: webvpn.cisco.com
   OU	Department Name
   O	Company Name (Avoid using Special Characters)
   C	Country Code (2 Letter Code without Punctuation)
   St	State (Must be spelled out completrly EX: North Carolina)
   L	City

   In order to configure these values, choose a value from the Attribute drop-down list, enter the value, and click Add.

   

   Note: Some 3rd party vendors require particular attributes to be included before an identity certificate is issued. If you are unsure of the required attributes, check with your vendor for details.

9. Once the appropriate values are added, click OK.

   The Add Identity Certificate dialog box appears with the Certificate Subject DN field populated.

10. Click Advanced.

    

11. In the FQDN field, enter the FQDN that will be used to access the device from the internet.

    This value should be same FQDN you used for the Common Name (CN).

12. Click OK, and then click Add Certificate.

    You are prompted to save the CSR to a file on your local machine.

    

13. Click Browse, choose a location in which to save the CSR, and save the file with the .txt extension.

    Note: When you save the file with a .txt extension, you can open the file with a text editor (such as Notepad) and view the PKCS#10 request.

14. Submit the saved CSR to your 3rd party vendor. Once you submit the CSR to your 3rd party vendor, they will provide you the identity certificate to be installed on the ASA.

Works well - GoDaddy / Starfield 5 year cert for $130

Bandwidth Throttling / Policing on Cisco ASA

August 17th, 2009 David Leave a comment Go to comments

If If you are looking to control the amount of bandwidth for a particular host using a Cisco ASA Security Appliance, you’ve come to the right place.  When I was first asked to look into this capability on the ASA I knew that I could perform some sort of Quality of Service (QOS).  In fact, all of the documentation that I came across either on Cisco’s website or from third party integrators have detailed information on controlling quality for VoIP, traffic shaping, and how to do those things across a VPN tunnel.  While the information on these great features of the ASA is helpful, finding articles on limiting bandwidth to a particular IP address was more difficult to track down.  In fact, it took a TAC case and several hours of reading papers on the above services until I was able to figure out how to police bandwidth using my ASA.  In the example below I am throttling bandwidth to 1Mb for the host 1.1.1.1:

For the sake of simplicity, I will show you how to limit inbound and outbound bandwidth for one host.  In order to do this for multiple hosts you simply replicate the steps making a few changes to access-list names, class-maps, and policy-maps.

The first step is to create the access list that define “interesting traffic” or what IP you want to control.

access-list throttle_me extended permit ip host 1.1.1.1 any
access-list throttle_me extended permit ip any host 1.1.1.1

The second step is to define the class-map.

class-map throttle-me
match access-list throttle_me

Now you need to define your policy-map and call the class-map.

policy-map throttle-policy
class throttle-me
police output 1000000 2000
police input 1000000 2000

The final step is to apply the new service-policy to the PHYSICAL interface where the traffic will flow.  You CANNOT apply this to a sub-interface.

service-policy throttle-policy interface outside

In summary, this configuration was applied to the outside interface of my ASA.  This is the “choke point” for traffic and can be considered the edge of my network.  As stated above, you must apply the policy to a physical interface on your ASA.  The IP address 1.1.1.1 represents a public address that is statically mapped to a private address behind a sub-interface on my ASA.  The method above combines a little bit of each QOS function from the ASA to get what I want it to do.

Using this on a WSUS server, works great.

forward a port on the ASA 5505 running version 8.3 from the CLI.  Some of you prefer to use the ASDM to do you changes, so I guess I'll show you how to do it from there.  The ASDM is a bit of a learning curve for someone that's used to the CLI, and most CLI guys hate a GUI with a great passion.  I can go either way.  I use the ASDM to make some changes simply because I want to learn it and there's some guys coming into the field today that were taught on the GUI rather than a command line.

In this lesson I'm using ASDM version 6.3(1) and ASA version 8.3(1).  Since we added a  web server in the last post, let's make this one an FTP server.  The FTP server's IP is the same as the web server, 10.9.8.7/24 and we're running over the standard FTP port, 21.

First off, we want to start up the ASDM and connect to the ASA.  Once there, click on the button at the top of the screen, then the button near the bottom left, and finally select near the top left.  You'll now be at a screen that looks something like this:

Click for larger version

Now we need to create a new object, so click on "Add" under Addresses, then "Network Object".
Now we need to fill out our new window.  Once you fill out the name, IP address and description, you need to drop down the NAT box and fill it out.  Click the "Add Automatic Address Translation Rules" box, leave the type as "static" and set the translated address as the outside interface.
We now need to go to the Advanced menu from the Add Network Object window and setup the port forwarding.  The source will be inside, destination is outside.  Protocol in this instance is TCP and our port is 21, both real and mapped.
Click "OK" twice and your object will be created as well as the port forward.  Now we just need to add the access rule.  On the left side of the screen, just above the NAT Rules is your Access Rules. From there we want to click "Add" and "Access Rule".
We need to create the rule on the outside interface, coming from any IP to the FTPServer using FTP as the service.
Once you click OK, your rule is added.  You don't have to add a description like I did in the image above this one, I just did that for the hell of it.  When you click "Apply" at the bottom of the screen, the ASDM will issue the commands to the ASA.  I have preview turned on, so I can always see what commands are being sent to the device before they are actually sent.  If you followed all the steps above and you have preview turned on, you'll see the following:
And you'll notice that those are the exact 4 commands that I gave in the last post about doing it from the CLI!  Now you can forward any port you want from either the CLI or the ASDM!

On a side note, I know a lot of guys hate the ASDM.  When I was writing this post and going through all of this I was kinda upset when I saw that I had 10 pictures for 4 lines of code.  The good thing about the ASDM is that you have everything right there at your disposal and you really don't need to know the vernacular of IOS.  The drawback is that it will take you longer to get things done at first, but once you get used to it, it can be just as fast.

Notes