Cisco Archives

The ASA 5500 series firewall can work as DHCP relay agent which means that it receives DHCP requests from clients on one interface and forwards the requests to a DHCP server on another interface. Usually the DHCP server is located in the same layer 3 subnet with its clients. There are situations however where we have only one DHCP server but several layer 3 networks exist (on different security zones on a Cisco ASA) and dynamic IP allocation is required for those networks as well. With the DHCP relay feature, we can connect the DHCP server on one network zone and have the firewall forward all DHCP requests from the other network zones to the DHCP server.

[ad#embedded-square]

The diagram below illustrates a simple network scenario with three security zones (network interfaces) and a single DHCP server. The three network zones are inside, outside and DMZ. The DHCP clients are connected to the inside network and the DHCP server on the DMZ network. The DHCP requests from the clients on the inside network will be relayed to the server on the DMZ network. The server will assign IP addresses in the range 192.168.1.0/24 to the clients.

Configuration

!First identify the DHCP server and the interface it Is connected to
ciscoasa# conf t
ciscoasa(config)# dhcprelay server 10.1.1.100 DMZ
ciscoasa(config)# dhcprelay timeout 90

!Now enable the DHCP relay on the inside interface
ciscoasa(config)# dhcprelay enable inside

!Assign the ASA inside interface IP as default gateway for the clients
ciscoasa(config)# dhcprelay setroute inside

Usage Guidelines

You can add up to four DHCP relay servers per interface. You must add at least one dhcprelay server command to the ASA Firewall configuration before you can enter the dhcprelay enable command. You cannot configure a DHCP client on an interface that has a DHCP relay server configured.

You cannot enable DHCP relay under the following conditions:
• You cannot enable DHCP relay and the DHCP relay server on the same interface.
• You cannot enable DCHP relay and a DHCP server (dhcpd enable) on the same interface.

This article describes the user interface and access modes and commands associated with the operation of Cisco ASA 5500 firewall appliances. We assume that you know how to connect to the appliance using a console cable (the blue flat cable with RJ-45 on one end, and DB-9 Serial on the other end) and a Terminal Emulation software (e.g HyperTerminal), and how to use basic Command Line Interface.

SECURITY APPLIANCE ACCESS MODES
A Cisco ASA security appliance has four main administrative access modes:

Monitor Mode: Displays the monitor> prompt. A special mode that enables you to update the image over the network or to perform password recovery. While in the monitor mode, you can enter commands to specify the location of a TFTP server and the location of the software image or password recovery binary image file to download. You access this mode by pressing the “Break” or “ESC” keys immediately after powering up the appliance.
Unprivileged Mode: Displays the > prompt. Available when you first access the appliance. If the appliance is a Cisco PIX 500 series, the prompt for unprivileged mode is pixfirewall> and if the appliance is the new Cisco ASA 5500 Series, the prompt is ciscoasa>

This mode provides restricted view of the security appliance. You cannot configure anything from this mode. To get started with configuration, the first command you need to know is the enable command. Type enable and hit Enter. The initial password is empty, so hit Enter again to move on the next access mode (Privileged Mode).

ciscoasa> enable <–Unprivileged Mode
password: <– Enter a password here (initially its blank)
ciscoasa# <– Privileged Mode
[ad#embedded-square]

Privileged Mode: Displays the # prompt. Enables you to change the current settings. Any unprivileged command also works in this mode. From this mode you can see the current configuration by using “show running-config”. Still, you cannot configure anything yet until you go to Configuration Mode. You access the Configuration Mode using the configure terminal command from the Privileged Mode.

Configuration Mode: This mode displays the (config)# prompt. Enables you to change all system configuration settings. Use exit from each mode to return to the previous mode.

ciscoasa> enable <– Unprivileged Mode
password: <– Enter a password here (initially its blank)
ciscoasa# configure terminal <– Privileged Mode
ciscoasa(config)# <– Configuration Mode
ciscoasa(config)# exit
ciscoasa# exit <– Back to Privileged Mode
ciscoasa> <– Back to Unprivileged Mode

The (config)# mode is sometimes called Global Configuration Mode. Some configuration commands from this mode enter a command-specific mode and the prompt changes accordingly. For example the interface command enters interface configuration mode as shown below:

ciscoasa(config)# interface GigabitEthernet0/1
ciscoasa(config-if)# <– Configure Interface specific parameters

Traditionally, a network firewall is a routed hop that acts as a default gateway for hosts that connect to one of its screened subnets. A transparent firewall (or Layer 2 firewall), on the other hand, acts like a “stealth firewall” and is not seen as a Layer 3 hop to connected devices. The appliance connects the same Layer 3 network subnet on its inside and outside ports, but each interface of the firewall resides in a different Layer 2 Vlan. The Cisco ASA firewall can operate both in Routed Firewall Mode (default mode) or in Transparent Firewall Mode.

Routed Firewall Mode:

See the diagram below for a common network topology of a Cisco ASA firewall working in Routed Mode.

As you can see, there are two different network subnets. Inside network (10.20.20.0/24) and Outside Network (10.10.10.0/24). There must be also two different layer2 vlans (Vlan20 for inside network and Vlan10 for outside network). All hosts residing in internal network must belong to subnet 10.20.20.0 and must have default gateway the internal IP of the ASA (10.20.20.1).

Transparent Firewall Mode:

The diagram below shows an example topology using a Cisco ASA in Layer 2 transparent mode.

As you can see, there is only one Layer 3 network (10.10.10.0/24) BUT there MUST be two different Layer 2 Vlans (Vlan20 for inside zone and Vlan10 for outside zone). All hosts must reside in network range 10.10.10.0 and the devices must have as default gateway the IP address of the outside router (10.10.10.2). Also, a management IP address MUST be configured on the ASA firewall (again within the range of 10.10.10.0). DO NOT specify the management IP address of the ASA as the default gateway for connected devices.

[ad#embedded-square]

Characteristics of Transparent Mode

• Transparent firewall mode supports only two interfaces (inside and outside)
• The firewall bridges packets from one VLAN to the other instead of routing them.
• MAC lookups are performed instead of routing table lookups.
• Can run in single firewall context or in multiple firewall contexts.
• A management IP address is required on the ASA.
• The management IP address must be in the same subnet as the connected network.
• Each interface of the ASA must be a different VLAN interface.
• Even though the appliance acts as a Layer 2 bridge, Layer 3 traffic cannot pass through the security appliance from a lower security level to a higher security level interface.
• The firewall can allow any traffic through by using normal extended Access Control Lists (ACL).

Initial Configuration

Asa(config)# firewall transparent

!Configure management IP below
Asa(config)# ip address 10.10.10.1 255.255.255.0

Asa(config)# interface Ethernet0/0
Asa(config-if)# nameif outside
Asa(config-if)# security-level 0
!
Asa(config)# interface Ethernet0/1
Asa(config-if)# nameif inside
Asa(config-if)# security-level 100

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).

[ad#embedded-square]

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”

Example1:

Allow only http traffic from inside network 10.0.0.0/24 to outside internet

ciscoasa(config)# access-list HTTP-ONLY extended permit tcp 10.0.0.0 255.255.255.0 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.

Example2:

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


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

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

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).

Example3:

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


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

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

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

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

Using Object Groups with Cisco ASA

The usage of object groups (network objects, service object etc) is becoming more popular on Cisco ASA firewalls especially with the new OS version 8.3(x). In this version, network object groups are used extensively for the configuration of NAT mechanisms in addition to other uses. In this post I will show a quick example of using network objects with access lists. In another post I will expand this to show how object groups are used with NAT as well.

Suppose we have a few Web servers located on a DMZ which are accessed from the Internet. We want to enable http (80) and https (443) access from internet towards these web servers.

Assume that we have configured static NAT for those web servers and translated their real private IP addresses to the following Public IP addresses:

Web Server1: 50.50.50.1
Web Server2: 50.50.50.2
Web Server3: 50.50.50.3

Configuration of access list using object groups:

! create a service group for the http and https protocols
object-group service http-protocols tcp
port-object eq 80
port-object eq 443

! create a network object group for the web servers
object-group network webservers
network-object host 50.50.50.1
network-object host 50.50.50.2
network-object host 50.50.50.3

! create the access list applied inbound on the outside interface
access-list OUTSIDE-IN extended permit tcp any object-group webservers object-group http-protocols

access-group OUTSIDE-IN in interface outside

EDIT (ASA Versions after 8.3):

In newer ASA versions after 8.3, the access list must always reference the Real IP address of a host and NOT the translated IP address. So, in our example above, the “webservers” object-group must include the Real (private) IP addresses of the servers and not the translated public IP.

! create a network object group for the web servers with their Real private IP
object-group network webservers
network-object host 192.168.1.1
network-object host 192.168.1.2
network-object host 192.168.1.3

! create the access list applied inbound on the outside interface
access-list OUTSIDE-IN extended permit tcp any object-group webservers object-group http-protocols

access-group OUTSIDE-IN in interface outside

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 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 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 1.1.1.1 type ipsec-l2l
tunnel-group 1.1.1.1 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 1.1.1.1 ipsec-attributes
pre-shared-key key123

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