Cisco Archives

One of the ways to configure authentication between two Cisco ASA firewalls having a site-to-site IPSec VPN tunnel between them is to configure a pre-shared key under the tunnel group attributes. This is actually the most common implementation of IPSEC lan-to-lan authentication that you will find in most real life networks.

The pre-shared key must be the same on both IPSEC VPN devices between which the secure tunnel is created. To configure the pre-shared key on a Cisco ASA:

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
pre-shared-key key123

Now, after configuring the pre-shared key, it is stored as encrypted hash on the ASA appliance and therefore when you view the running configuration (show run) you don’t see the actual clear text key anymore (i.e instead of “key123” you will see “*”).

Ciscoasa# show run

tunnel-group type ipsec-l2l
tunnel-group ipsec-attributes
pre-shared-key *

The problem arises when you forget the pre-shared key after a few months and you want to change one of the VPN tunnels. This situation happened to me recently when I had to change the public IP address on one of the ASA sites which had a Lan-to-Lan tunnel with a second ASA. Therefore I had to reconfigure the tunnel group and re-enter the old pre-shared key. However, I did not have it stored in clear text anywhere. The way to recover the pre-shared key is actually simple. Use the more system:running-config command. This command shows the pre-shared key in clear text format:

Ciscoasa# more system:running-config

tunnel-group ipsec-attributes
pre-shared-key key123

The following article describes how to configure Access Control Lists (ACL) on Cisco ASA 5500 firewalls. An ACL is the central configuration feature to enforce security rules on your network.

The Cisco ASA 5500 is the new Cisco firewall model series which followed the successful Cisco PIX firewall appliance. Cisco calls the ASA 5500 a “security appliance” instead of just a “hardware firewall”, because the ASA is not just a firewall. This device combines several security functionalities, such as Intrusion Detection, Intrusion Prevention, Content Inspection, Botnet Inspection, in addition to the firewall functionality.

However, the core ASA functionality is to work as a high performance firewall. All the other security features are just complimentary services on top of the firewall functionality. Having said that, the purpose of a network firewall is to protect computer and IT resources from malicious sources by blocking and controlling traffic flow. The Cisco ASA firewall achieves this traffic control using Access Control Lists (ACL).

An ACL is a list of rules with permit or deny statements. Basically an Access Control List enforces the security policy on the network. The ACL (list of policy rules) is then applied to a firewall interface, either on the inbound or on the outbound traffic direction. If the ACL is applied on the inbound traffic direction (in), then the ACL is applied to traffic entering a firewall interface. The opposite happens for ACL applied to the outbound (out) direction.

The ACL permit or deny statements basically consist of source and destination IP addresses and ports. A permit ACL statement allows the specified source IP address/network to access the specified destination IP address/network. The opposite happens for deny ACL statements. At the end of the ACL, the firewall inserts by default an implicit DENY ALL statement rule which is not visible in the configuration.

Enough theory so far. Let us see some examples below to clarify what we have said above.

The basic command format of the Access Control List is the following:

ciscoasa(config)# access-list “access_list_name” extended {deny | permit} protocol “source_address” “mask” [source_port] “dest_address” “mask” [ dest_port]

To apply the ACL on a specific interface use the access-group command as below:

ciscoasa(config)# access-group “access_list_name” [in|out] interface “interface_name”

Example 1:

Allow only http traffic from inside network to outside internet

ciscoasa(config)# access-list HTTP-ONLY extended permit tcp any eq 80

ciscoasa(config)# access-group HTTP-ONLY in interface inside

The name “HTTP-ONLY” is the Access Control List itself, which in our example contains only one permit rule statement. Remember that there is an implicit DENY ALL rule at the end of the ACL which is not shown by default.

Example 2:

Deny telnet traffic from host to host and allow everything else.

ciscoasa(config)# access-list DENY-TELNET extended deny tcp host host eq 23

ciscoasa(config)# access-list DENY-TELNET extended permit ip host host

ciscoasa(config)# access-group DENY-TELNET in interface inside

The above example ACL (DENY-TELNET) contains two rule statements, one deny and one permit. As we mentioned above, the “access-group” command applies the ACL to an interface (either to an inbound or to an outbound direction).

Example 3:

The example below will deny ALL TCP traffic from our internal network towards the external network Also, it will deny HTTP traffic (port 80) from our internal network to the external host All other traffic will be permitted from inside.

ciscoasa(config)# access-list INSIDE_IN extended deny tcp

ciscoasa(config)# access-list INSIDE_IN extended deny tcp host eq 80

ciscoasa(config)# access-list INSIDE_IN extended permit ip any any

ciscoasa(config)# access-group INSIDE_IN in interface inside

A very popular scenario for small networks is to have a Cisco ASA 5505 as border firewall connecting the LAN to the Internet. Administrators in such networks are usually encountered with requests from their users that are not very security conscious. Such a request could be to allow Remote Desktop access from the Internet to an internal Windows server. This might be very helpful for users who want to work from home but I would not recommend it. If you have to implement such a scenario, I suggest that you put the Remote Desktop server in a DMZ and not directly in the internal network. However, companies with limited budget might have purchased a Cisco ASA 5505 with basic license which restricts the creation of a DMZ Vlan (although you can create 3 Vlans, the third Vlan can only communicate with one of the other two Vlans but not both). So, let’s see a typical network topology with ASA 5505 basic license and an internal Remote Desktop server.

Again, I don’t recommend such a network topology as shown above. Remote Desktop machines are very prone to attacks, especially brute-force password attacks. In windows, the administrator account does not get locked-out by default. So a brute force administrator password attack on the RDP server from remote attackers can be successful especially if the administrator password is weak. In any case, if you are “forced” to implement such a scenario, here is the configuration:


Assume that the ASA receives IP address dynamically from the ISP (via DHCP protocol). So the outside IP of the ASA is not fixed. Therefore, we will configure static NAT with port redirection using the outside interface. Since the outside address is dynamic, you can use a service such as DynDNS to get a fixed domain name irrespective of the IP mapped with it. The following is a configuration snapshot for ASA versions prior to 8.3 and for ASA 8.3 as well.

ASA version prior to 8.3
ciscoasa(config)# static (inside , outside) tcp interface 3389 3389 netmask
ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any any eq 3389
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

ASA version 8.3 and later
ciscoasa(config)# object network RDP_static
ciscoasa(config-network-object)# host
ciscoasa(config-network-object)# nat (inside , outside) static interface service tcp 3389 3389
ciscoasa(config)# access-list OUTSIDE-IN extended permit tcp any host eq 3389
ciscoasa(config)# access-group OUTSIDE-IN in interface outside

NOTE: Notice that in version 8.3 we reference the Real IP address ( in the access-list and not the mapped IP

Cisco ASA supports two major WebVPN modes: Clientless WebVPN and Anyconnect WebVPN.

Let’s see the differences between the two WebVPN modes and I’m sure you will understand why the AnyConnect mode is much better in my opinion.

Clientless WebVPN does not require any VPN client to be installed on user’s computer. It uses a normal web browser. By pointing the browser to https://[outside address of ASA] the user authenticates with the firewall and gets access to a Web Portal. Through this Web Portal, the user can then access a limited number of internal applications. Specifically, only internal Web applications (HTTP, HTTPs), email servers (POP3, SMTP, IMAP), Windows file shares and a small number of TCP legacy applications (e.g Telnet) can be accessed. That is, there is no full network connectivity with Clientless WebVPN.


AnyConnect WebVPN, on the other hand, provides FULL network connectivity to the remote user. The ASA firewall, working as AnyConnect WebVPN server, assigns an IP address to the remote user and attaches the user to the network. Thus, all IP protocols and applications function across the SSL VPN tunnel without any problems. For example, a remote user, after successfully authenticated with AnyConnect VPN, can open a Remote Desktop connection and access a Windows Terminal Server inside the central network. Although a special Java-based client is required to be installed on the user’s desktop, this client can be supplied dynamically to the user from the ASA. The user can connect with a browser to the ASA firewall and download the Java client on demand. The Java client can remain installed or even get removed from the user’s desktop when disconnected from the ASA appliance. This Java client is small in size (around 3MB) and is stored on the ASA flash memory.

Access Control Lists (ACLs) are sequential lists of permit and deny conditions applied to traffic flows on a device interface. ACLs are based on various criteria including protocol type source IP address, destination IP address, source port number, and/or destination port number.

ACLs can be used to filter traffic for various purposes including security, monitoring, route selection, and network address translation. ACLs are comprised of one or more Access Control Entries (ACEs). Each ACE is an individual line within an ACL.


ACLs on a Cisco ASA Security Appliance (or a PIX firewall running software version 7.x or later) are similar to those on a Cisco router, but not identical. Firewalls use real subnet masks instead of the inverted mask used on a router. ACLs on a firewall are always named instead of numbered and are assumed to be an extended list.

The syntax of an ACE is relatively straight-forward:

Ciscoasa(config)#access-list name [line number] [extended] {permit | deny} protocol

source_IP_address source_netmask [operator source_port] destination_IP_address

destination_netmask [operator destination_port] [log [[disable | default] | [level]] [interval seconds]] [time-range name] [inactive]

Here’s an example:

asa(config)# access-list demo1 permit tcp any eq www

asa(config)# access-list demo1 permit tcp any eq 443

asa(config)# show access-list demo1

access-list demo1; 2 elements

access-list demo1 line 1 extended permit tcp any eq www

access-list demo1 line 2 extended permit tcp any eq https

In the above example, an ACL called “demo1″ is created in which the first ACE permits TCP traffic originating on the subnet to go to any destination IP address with the destination port of 80 (www). In the second ACE, the same traffic flow is permitted for destination port 443. Notice in the output of the show access-list that line numbers are displayed and the extended parameter is also included, even though neither was included in the configuration statements.

You can deactivate an ACE without deleting it by appending the inactive option to the end of the line.

As with Cisco routers, there is an implicit “deny any” at the end of every ACL. Any traffic that is not explicitly permitted is implicitly denied.

**Editing ACLs and ACEs**

New ACEs are appended to the end of the ACL. If you want, however, to insert the new ACE at a particular location within the ACL, you can add the line number parameter to the ACE:

asa04(config)# access-list demo1 line 1 deny tcp host any eq www

asa04(config)# show access-list demo1

access-list demo1; 3 elements

access-list demo1 line 1 extended deny tcp host any eq www

access-list demo1 line 2 extended permit tcp any eq www

access-list demo1 line 3 extended permit tcp any eq https

Notice in the first line of the example above that an ACE is added at line one in the ACL. Notice in the output from the show access-list demo1 command that the new entry is added in the first position in the ACL and the former first entry becomes line number two.

You can remove an ACE from an ACL by preceding the ACE configuration statement with the modifier no, as in the following example:

Asa04(config)#no access-list demo1 deny tcp host any eq www

In my next article, I’ll show you how to use time-ranges to apply access-control lists only at certain times and/or on certain days. I’ll also show you how to use object-groups with access-control lists to simplify ACL management by grouping similar components such as IP addresses or protocols together.

Copyright (c) 2008 Don R. Crawley

Don R. Crawley, CCNA-certified, is president and chief technologist at, the Seattle training firm specializing in business skills and technical training for IT professionals.

Article Source:

Allowing Microsoft PPTP through Cisco ASA

The Microsoft Point to Point Tunneling Protocol (PPTP) is used to create a Virtual Private Network (VPN) between a PPTP client and server. It is used for remote access from mobile users to connect back to their corporate network over the Internet. A PPTP client connects and authenticates to the PPTP server which assigns an IP address to the client and attaches the remote user to the network. After that, the remote user has full network connectivity just like being connected locally.

In the older PIX version 6.x, you could configure the PIX firewall itself to work as a PPTP server, thus you didn’t even need to have a Windows PPTP server in place. With the new ASA firewall however, you cannot terminate PPTP on the ASA itself. Therefore you must have a Microsoft PPTP server in the network in order to terminate PPTP connections from clients.


PPTP uses two protocols: GRE to encapsulate PPP packets and a control channel at TCP port 1723. Any stateful firewall would have a problem with allowing PPTP protocol without any special “fixup” because of the two protocols needed for communication (GRE and TCP 1723). Cisco ASA allows you to pass PPTP traffic through with a special “inspection” mechanism which checks the control traffic (TCP 1723) in order to dynamically open also access for GRE traffic to pass through with no problems.

In this post we will see two scenarios of allowing PPTP traffic through a Cisco ASA. In the first scenario we have a PPTP client on the inside of ASA which communicates with a PPTP server on the outside zone. In the second scenario we have a PPTP client on the outside of ASA which communicates with a PPTP server on the inside.

Scenario 1: PPTP client on inside and server on outside

The first scenario above depicts a PPTP server located on the outside of the ASA (Internet) and PPTP clients on the inside. Using the “inspect” command in the global policy-map we can enable access from inside to outside for PPTP.

! enable Port Address Translation on the outside interface
ciscoasa(config)#nat (inside) 1 0 0
ciscoasa(config)#global (outside) 1 interface

! Add PPTP inspection to the default policy-map using the default class-map
ciscoasa(config)# policy-map global_policy
ciscoasa(config-pmap)# class inspection_default
ciscoasa(config-pmap-c)# inspect pptp

Scenario 2: PPTP client on outside and server on inside

This scenario depicts a PPTP server located on the inside network. Here we must configure static NAT for the PPTP server and allow the appropriate protocols from outside (GRE, TCP 1723)

! translate the PPTP server private address to public
ciscoasa(config)# static (inside,outside) netmask

! allow the appropriate protocols from outside to inside
ciscoasa(config)# access-list acl-out permit gre any host
ciscoasa(config)# access-list acl-out permit tcp any host eq 1723
ciscoasa(config)# access-group acl-out in interface outside

Cisco ASA 5505 User License Explained

I get a lot of questions regarding the meaning of user license numbers for the Cisco ASA 5505. This model is offered in three User License options. 10 users, 50 users and UL (unrestricted license). The meaning of user license basically refers to concurrent IP addresses that can communicate between Internal (inside) network and Internet (outside) interface. So, for 10 user license, only 10 concurrent internal hosts (IP addresses) can access the internet. The same applies for 50 users (only 50 concurrent IP addresses can access the Internet). For UL license, there is no such restriction.

The user licensing has also an effect on the maximum number of IP addresses that can be assigned by the DHCP server of the ASA5505 to the internal hosts. For a 10-user license, the max number of DHCP clients on the internal network is 32. For 50-user license, the max number of DHCP clients is 128.

The official explanation from Cisco regarding the Cisco ASA5505 user licensing is as follows:

“In routed mode, hosts on the inside (Business and Home VLANs) count towards the limit only when they communicate with the outside (Internet VLAN). Internet hosts are not counted towards the limit. Hosts that initiate traffic between Business and Home are also not counted towards the limit. The interface associated with the default route is considered to be the Internet interface. If there is no default route, hosts on all interfaces are counted toward the limit. In transparent mode, the interface with the lowest number of hosts is counted towards the host limit. See the show local-host command to view host limits. “

The terms “Business” and “Home” VLANs above refer to the Internal and DMZ network zones.

How to Pass Your CCNA Exam

If you really want to know how to pass you CCNA (Cisco Certified Network Associate) exam then you’ll want to read every word of this article. There are several key areas that you need to master in order for your best chance of success to pass the CCNA test.

You will want to get comfortable with all the different realms of information. Like anything else that you want to achieve, the true keys is not whether you can gather a multitude of books, manuals or other learning materials, it’s whether you have the determination and drive to get the job done.

There are so many types of learning guides and materials out there, so many in fact that sometimes you can be burdened down with information overload. This is where you continually seek out new material, and there is a ton of it out there, you have so much that it all becomes very confusing instead of easier. Many of the so called ‘can’t miss’ study courses that are offered only give you a false sense of knowledge.

Once you realize that in order to pass your CCNA exam, it will take some hard work and dedication on your part, as it is a very difficult test to pass, will your journey get better.

Once you decide that you are ready to embark on the journey of passing the CCNA exam, the next step is to set out a realistic time frame to do so. When you set this time frame, be honest with yourself. There’s nothing worse then trying to complete the Cisco certification in less time than you are physically or mentally able to handle.
Once a realistic time frame is in place, it is nice to have a calendar with your time schedule in front of you to keep you focused and determined to meet your schedule. Also, a weekend excursion away, a bottle of finely aged wine, or anything that will keep you going when the times get tough are all recommended.

Now, the CCNA exam is one of those certifications that a proper training is required to pass it. You can go for an instructor class-based training (usually 5-day boot camp) and get the required training. However this option is very expensive and study intensive since you are not studying on your own pace. The other great option is to get a computer based training (usually video training style) where you get videos plus audio plus many practice questions and instructor notes for a complete training in your home. What I used personally and passed my Cisco exams (CCNA, CCNP, CCSP) is the Trainsignal Video Training packages which offer excellent value and in-depth training to pass the CCNA or any other Cisco exam. Check out Trainsignal Website for more information.  

In addition to the training I suggest above, I also recommend you to get some tangible book study material that others have used and been successful with. Here are some books that you should look into:

  1. Cisco Press CCNA Study Guide
  2. Jeremy Cioara’s Exam Cram and Prep Guide
  3. Any books on the subject by Todd Lammle.

I highly recommend the Cisco Press books. These books are usually the best because they come from the actual exam giver, Cisco. Therefore, the exercises and test questions will be very relevant to what you’ll see on the exam. Moreover, a Cisco Press book will be a great reference even after you pass your CCNA exam.

Having some highlighters and a note pad is a must in order to go back for easy review of any of the topic that you studied. When ever you have some extra time, even just five or ten minutes, you can whip out your study notes and do a quick review. This will keep you sharp, and get you into some good study habits.

Perhaps the best resource that you can find is the actual people that have gone through and passed their CCNA exam. You don’t have to have a face to face with them. Because of the speed and convenience of the Internet, you can search them online and seek any and all information you need.

Talking with these people that have gone through and learned how to pass the CCNA exam is an easier way to learn then any book or course that you could buy. Real life experience is better then any book ever printed. Good luck for your CCNA certification efforts.

 Page 4 of 10  « First  ... « 2  3  4  5  6 » ...  Last »