Posts Tagged ‘pix’
As I am sure you have already seen from the blog on setting up the security device as a Layer 2 device, there are many interesting changes that occur on a PIX or ASA when configured for transparent operations. This blog highlights the major changes and guidelines that you should keep in mind when you opt for this special mode of operation.
- Number of interfaces – perhaps on of the biggest things you will want to keep in mind is the fact that you are going to be limited on the number of traffic forwarding interfaces you can use when in Layer 2 mode. When you switch to transparent mode, you are limited to the use of two traffic forwarding interfaces. On some ASA models, you may also use your dedicated management interface, but of course, the use of this port is limited for management traffic. Remember also, when in multiple context mode, you cannot share interfaces between contexts like you can when in routed mode.
- IP addressing – here is another major difference of course. In Layer 2 mode, you will assign a single IP address to the device in Global Configuration mode. This address is for remote management purposes and is required before the device will forward traffic. Once the address is assigned, all interfaces start “listening” on this address to ensure the device is responsive to its administrator. This global IP addressed assigned to the device must be in the same subnet that the forwarding interfaces are participating in. Remember, the transparent firewall is not adding a new network (subnet) to your topology.
- Default gateway – for traffic sourced from the security device itself, you can configure a default gateway on the transparent device. You can do this with the route 0 0 command.
- IPv6 support - the transparent firewall does not support IPv6.
- Non-IP traffic – you can pass non-IP traffic through the Layer 2 Mode device. Note that this is not possible on a security appliance in its default Layer 3 mode.
- More unsupported features – the Layer 2 mode device does not support – Quality of Service (QoS) or Network Address Translation (NAT).
- Multicast – the transparent mode device does not offer multicast support, but you can configure Access Control Lists (ACLs) in order to pass multicast traffic through the device.
- Inspection – with the Layer 2 mode device you can inspect traffic at Layer 2 and above. With the classic routed mode configuration, you can only inspect at Layer 3 and above.
- VPN support – the transparent mode device does support a site to site VPN configuration, but only for its management traffic.
This blog will examine the basic setup of the transparent firewall feature available with the PIX and the ASA. This blog was based on the PIX-525 running 7.2(4) code with a Restricted license in GNS3. Here is the topology that was used:
Remember, that a transparent firewall resides WITHIN a subnet and is easy to implement in an existing network where re-addressing to introduce a firewall might be difficult. This configuration is sometimes known as a “stealth” firewall or a “bump on the wire”. Thanks to the fact that the firewall lives within the subnet, instead of between it, the device has the ability to filter traffic between hosts within the subnet. Note that the traditional Layer 3 firewall can only filter traffic moving between subnets. This should remind you of the difference between a VLAN Access Control List versus a Router-based Access Control List.
Well, with the introductions out of the way, let’s do what we love best, let’s get to the command line.
The first thing I will do is configure and verify the transparent firewall feature and then name our PIX:
pixfirewall> en Password: pixfirewall# conf t pixfirewall(config)# firewall transparent pixfirewall(config)# show firewall Firewall mode: Transparent pixfirewall(config)# hostname LAYER2FIREWALL LAYER2FIREWALL(config)#
Excellent, now that the firewall is in transparent mode, let’s take care of the inside and outside interfaces. When in transparent mode, you are limited to the use of two interfaces for passing traffic. Notice how the interfaces are not configured with IP addresses.
LAYER2FIREWALL(config)# int e1 LAYER2FIREWALL(config-if)# nameif inside INFO: Security level for "inside" set to 100 by default. LAYER2FIREWALL(config-if)# no shut LAYER2FIREWALL(config-if)# exit LAYER2FIREWALL(config)# int e0 LAYER2FIREWALL(config-if)# nameif outside INFO: Security level for "outside" set to 0 by default. LAYER2FIREWALL(config-if)# no shut LAYER2FIREWALL(config-if)# sh int ip brief Interface IP-Address OK? Method Status Protocol Ethernet0 unassigned YES unset up up Ethernet1 unassigned YES unset up up Ethernet2 unassigned YES unset administratively down up Ethernet3 unassigned YES unset administratively down up Ethernet4 unassigned YES unset administratively down up
I am sure this output looks a little strange for those of you that have not played with this feature. Just as unusual is the fact that all of the interfaces facing this device are addressed in the 10.0.0.0/24 subnet.
A requirement of the transparent firewall is that it must have an IP address assigned in global configuration mode for management access. Notice for verification we can see that our traffic forwarding interfaces are now “listening” on that IP address:
LAYER2FIREWALL(config)# ip address 10.0.0.22 255.255.255.0 LAYER2FIREWALL(config)# sh int ip brief Interface IP-Address OK? Method Status Protocol Ethernet0 10.0.0.22 YES unset up up Ethernet1 10.0.0.22 YES unset up up Ethernet2 unassigned YES unset administratively down up Ethernet3 unassigned YES unset administratively down up Ethernet4 unassigned YES unset administratively down up
Let us now test the “out of the box” functionality of the security device. I will initiate a Telnet session from the Inside interface to a device located on the Outside interface. This communication should be permitted due to the Adaptive Security Algorithm and the default security levels on our interfaces. Notice how we can easily verify the connection of the appliance.
R1#telnet 10.0.0.10 Trying 10.0.0.10 ... Open User Access Verification Password: R0> LAYER2FIREWALL(config)# show conn 1 in use, 1 most used TCP outside 10.0.0.10:23 inside 10.0.0.1:25501, idle 0:00:03, bytes 102, flags UIO
Let’s now permit Telnet connections from our management workstation (played by R2) and ensure we have connectivity to the PIX.
LAYER2FIREWALL(config)# telnet 10.0.0.20 255.255.255.255 Inside
R2#telnet 10.0.0.22 Trying 10.0.0.22 ... Open User Access Verification Password: Type help or '?' for a list of available commands. LAYER2FIREWALL>
Well, I am sure I will blog more on this Layer 2 firewall at a later point, but I sure do thank you for stopping by to read this initial post.
Thanks to Anisha with Cisco Systems for this idea. We were in Brian McGahan’s CCIE Security 5 Day Bootcamp, and she realized it would be nice to have a Quick Ref of his troubleshooting/verification commands. There is a bazillion shows and debugs it seems, but you only need a subset to be successful in the lab. Here is the first part of the “cheat sheet”. The rest will follow in the respective categories in the blog. Please let me know via comment if you see errors or have additions. I added to Brian’s classroom commands with some of my own. I also took a few from the Cisco Press ASA All-In-One Guide. It is an excellent text for your Kindle!
show aaa-server protocol PROTOCOL_NAME
Access Control Lists
show run | include ACCESS_LIST_NAME
show run object-group
show run time-range
show conn state STATE_TYPE detail
show int ip brief
show run interface INTERFACE_NAME
Connections and Translations
show conn detail
show local-host all
clear local-host all (clears all connections)
show run | begin policy-map
show run global
show run nat
debug fo rxip
debug fo txip
deug ospf event
show ospf database
show ospf interface
show ospf neighbor
show ospf PROCESS_ID
show ospf virtual-links
show igmp interface
show pim interface
show pim neighbor
debug crypto ca messages
debug crypto ca transactions
show crypto ca certificates
show crypto ca crls
show crypto key mypubkey rsa
Quality of Service
show priority-queue statistics
show run class-map
show run policy-map
show service-policy global
show service-policy interface INTERFACE_NAME
show service-policy priority
show service-policy shape
show crypto key mypubkey rsa
show ntp status
show snmp-server statistics
show ssh sessions
debug crypto ipsec
debug crypto isakmp
show crypto ipsec sa
show crypto isakmp sa detail
debug menu wbvpn
debug ssl cipher
show vpn-sessiondb summary
show vpn-sessiondb webvpn
In this final part of our blog series on QoS with the PIX/ASA, we examine the remaining two tools that we find on some devices – traffic shaping and traffic policing.
Traffic shaping on the security appliance allows the device to limit the flow of traffic. This mechanism will buffer traffic over the “speed limit” and attempt to send the traffic later. On the 7.x security device, traffic shaping must be applied to all outgoing traffic on a physical interface. Shaping cannot be configured for certain types of traffic. The shaped traffic will include traffic passing though the device, as well as traffic that is sourced from the device.
In order to configure traffic shaping, use the class-default class and apply the shape command in Policy Map Class Configuration mode. This class-default class is created automatically for you by the system. It is a simple match any class map that allows you to quickly match all traffic. Here is a sample configuration:
pixfirewall(config-pmap)#policy-map PM-SHAPER pixfirewall(config-pmap)# class class-default pixfirewall(config-pmap-c)# shape average 2000000 16000 pixfirewall(config-pmap-c)# service-policy PM-SHAPER interface outside
Verification is simple. You can run the following to confirm your configuration:
pixfirewall(config)# show run policy-map ! policy-map PM-SHAPER class class-default shape average 2000000 16000 !
Another excellent command that confirms the effectiveness of the policy is:
pixfirewall(config)# show service-policy shape Interface outside: Service-policy: PM-SHAPER Class-map: class-default shape (average) cir 2000000, bc 16000, be 16000 Queueing queue limit 64 packets (queue depth/total drops/no-buffer drops) 0/0/0 (pkts output/bytes output) 0/0
With a policing configuration, traffic that exceeds the “speed limit” on the interface is dropped. Unlike traffic shaping configurations on the appliance, with policing you can specify a class of traffic that you want the policing to effect. Let’s examine a traffic policing configuration. In this configuration, we will limit the amount of Web traffic that is permitted in an interface.
pixfirewall(config)# access-list AL-WEB-TRAFFIC permit tcp host 192.168.1.110 eq www any pixfirewall(config-if)# class-map CM-POLICE-WEB pixfirewall(config-cmap)# match access-list AL-WEB-TRAFFIC pixfirewall(config-cmap)# policy-map PM-POLICE-WEB pixfirewall(config-pmap)# class CM-POLICE-WEB pixfirewall(config-pmap-c)# police input 1000000 conform-action transmit exceed-action drop pixfirewall(config-pmap-c)# service-policy PM-POLICE-WEB interface outside
Notice we can verify with similar commands that we used for shaping!
pixfirewall(config)# show run policy-map ! policy-map PM-POLICE-WEB class CM-POLICE-WEB police input 1000000 ! pixfirewall(config)# show ser pixfirewall(config)# show service-policy police Interface outside: Service-policy: PM-POLICE-WEB Class-map: CM-POLICE-WEB Input police Interface outside: cir 1000000 bps, bc 31250 bytes conformed 0 packets, 0 bytes; actions: transmit exceeded 0 packets, 0 bytes; actions: drop conformed 0 bps, exceed 0 bps
I hope that you enjoyed this four part series on QoS on the PIX/ASA! Please look for other posts about complex configurations on the security appliances very soon. I have already been flooded with recommendations!
The security appliance supports two kinds of priority queuing – standard priority queuing and hierarchical priority queuing. Let’s configure each in this third part of our blog.
Standard Priority Queuing
This queuing approach allows you to place your priority traffic in a priority queue, while all other traffic is placed in a best effort queue. You can police all other traffic if needed.
Step 1: Create the priority queue on the interface where you want to configure the standard priority queuing. This is done in global configuration mode with the priority-queue interface_name command. Notice this will place you in priority queue configuration mode where you can optionally manipulate the size of the queue with the queue-limit number_of_packets command. You can also optionally set the depth of the hardware queue with the tx-ring-limit number_of_packets command. Remember that the hardware queue forwards packets until full, and then queuing is handled by the software queue (composed of the priority and best effort queues).
pixfirewall(config)# priority-queue outside pixfirewall(config-priority-queue)#
Step 2: Use the Modular Policy Framework (covered in Part 2 of these blogs) to configure the prioritized traffic.
pixfirewall(config-priority-queue)# exit pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# service-policy PM-VOICE-TRAFFIC interface outside pixfirewall(config)# end
Hierarchical Priority Queuing
This queuing approach allows you to shape traffic and allow a subset of the shaped traffic to be prioritized. I have cleared the configuration from the security appliance in preparation for this new configuration. Notice with this approach, you do not configure a priority queue on the interface. Also notice with this approach the nesting of the Policy Maps.
pixfirewall(config)# class-map CM-VOICE pixfirewall(config-cmap)# match dscp ef pixfirewall(config-cmap)# exit pixfirewall(config)# class-map CM-VOICE-SIGNAL pixfirewall(config-cmap)# match dscp af31 pixfirewall(config-cmap)# exit pixfirewall(config)# policy-map PM-VOICE-TRAFFIC pixfirewall(config-pmap)# class CM-VOICE pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# class CM-VOICE-SIGNAL pixfirewall(config-pmap-c)# priority pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# exit pixfirewall(config)# policy-map PM-ALL-TRAFFIC-SHAPE pixfirewall(config-pmap)# class class-default pixfirewall(config-pmap-c)# shape average 2000000 16000 pixfirewall(config-pmap-c)# service-policy PM-VOICE-TRAFFIC pixfirewall(config-pmap-c)# exit pixfirewall(config-pmap)# service-policy PM-ALL-TRAFFIC-SHAPE interface outside pixfirewall(config)# end
Verifications for Priority Queuing
These verification commands can be used for both forms of priority queuing. Obviously, you can examine portions of the running configuration to confirm your Modular Policy Framework components. For example:
pixfirewall# show run policy-map ! policy-map PM-VOICE-TRAFFIC class CM-VOICE priority class CM-VOICE-SIGNAL priority class class-default policy-map PM-ALL-TRAFFIC-SHAPE class class-default shape average 2000000 16000 service-policy PM-VOICE-TRAFFIC !
pixfirewall# show run class-map ! class-map CM-VOICE-SIGNAL match dscp af31 class-map CM-VOICE match dscp ef !
To verify the statistics of the standard priority queuing configuration, use the following:
pixfirewall# show service-policy priority Interface outside: Service-policy: PM-VOICE-TRAFFIC Class-map: CM-VOICE Priority: Interface outside: aggregate drop 0, aggregate transmit 0 Class-map: CM-VOICE-SIGNAL Priority: Interface outside: aggregate drop 0, aggregate transmit 0
You can also view the priority queue statistics for an interface using the following:
pixfirewall# show priority-queue statistics outside Priority-Queue Statistics interface outside Queue Type = BE Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0 Queue Type = LLQ |Tail Drops = 0 Reset Drops = 0 Packets Transmit = 0 Packets Enqueued = 0 Current Q Length = 0 Max Q Length = 0
To verify the statistics on the shaping you have done with the hierarchical priority queuing, use the following:
pixfirewall# show service-policy shape Interface outside: Service-policy: PM-ALL-TRAFFIC-SHAPE Class-map: class-default shape (average) cir 2000000, bc 16000, be 16000 (pkts output/bytes output) 0/0 (total drops/no-buffer drops) 0/0 Service-policy: PM-VOICE-TRAFFIC
The next blog entry on this subject will focus on the shape tool available on the PIX/ASA.
Thanks so much for reading!
How do you apply most of your QoS mechanisms on a Cisco router? You use the Modular Quality of Service Command Line Interface (MQC). The approach is similar on the PIX/ASA, but the tool does feature some important differences. Also, Cisco has renamed the tool to the Modular Policy Framework. One reason for this is the fact that it is used for more than just QoS. For example, the MPF is also used for application inspection and Intrusion Prevention configurations on the ASA.
The three steps used by MPF are pretty famous at this point. Here they are:
Step 1: Define the traffic flows that you want to manipulate using what is called a Class Map. Do not confuse this with a Map Class that you might remember from Frame Relay configurations. A nice analogy for the Class Map is a bucket that you are pouring the traffic into that you want to manipulate.
Step 2: Take those buckets of traffic from Step 1 and define the particular policy that will apply. The structure used for this is called a Policy Map. An example might be to police Web traffic (defined in a Class Map) to a particular rate.
Step 3: Assign the Policy Map to an interface or all interfaces on the system using what is called a Service Policy.
Let’s examine the syntax for these various commands.
pixfirewall(config)# class-map ? configure mode commands/options: WORD < 41 char class-map name type Specifies the type of class-map
Notice the Class Map syntax includes a type option on the security appliance, the possible types include inspect, management, and regex and represent the variety of configurations the Modular Policy Framework can carry out.
Something else interesting about the Class Map on the security appliance is the fact that there is no options for match-any or match-all. This is because on the security appliance you can only have one match statement. There are exceptions to this, and that is after using either the match tunnel-group or match default-inspection-traffic commands.
Here you can see the match options on the security appliance to fill these buckets of traffic:
pixfirewall(config-cmap)# match ? mpf-class-map mode commands/options: access-list Match an Access List any Match any packet default-inspection-traffic Match default inspection traffic: dscp Match IP DSCP (DiffServ CodePoints) flow Flow based Policy port Match TCP/UDP port(s) precedence Match IP precedence rtp Match RTP port numbers tunnel-group Match a Tunnel Group
Obviously, a powerful option is the ability to match on an access list, since this allows matching on very specific criteria, such as well Web traffic requests from a source to a specific destination. Here is an example:
pixfirewall(config)# access-list AL-EXAMPLE permit tcp any host 10.10.10.200 eq www pixfirewall(config)# class-map CM-EXAMPLE pixfirewall(config-cmap)# match access-list AL-EXAMPLE
For step 2, we use the Policy Map. There are also types of these components that can be created. Notice that you are not in Policy Map configuration mode long, you switch immediately to Policy Map Class configuration mode to get your configuration complete.
pixfirewall(config)# policy-map PM-EXAMPLE pixfirewall(config-pmap)# class CM-EXAMPLE pixfirewall(config-pmap-c)# police output 56000 10500
Here you can see the third strep. The Service Policy applies the Policy Map. You can assign the Policy Map to an interface or all interfaces with the following syntax:
pixfirewall(config)# service-policy PM-EXAMPLE global
Here is a single interface example:
service-policy PM-EXAMPLE interface inside
Notice that a direction is not specified as you would on a router. Notice the direction of policing was actually specified in the Policy Map.
What happens if there is a global policy and an interface policy? Well the interface policy wins out and controls the interface.
The next blog entry on this subject will focus on the priority queuing tool available on the security appliance.
This blog is focusing on QoS on the PIX/ASA and is based on 7.2 code to be consistent with the CCIE Security Lab Exam as of the date of this post. I will create a later blog regarding new features to 8.X code for all of you non-exam biased readers
NOTE: We have already seen thanks to our readers that some of these features are very model/license dependent! For example, we have yet to find an ASA that allows traffic shaping.
One of the first things that you discover about QoS for PIX/ASA when you check the documentation is that none of the QoS tools that these devices support are available when you are in multiple context mode. This jumped out at me as a bit strange and I just had to see for myself. Here I went to a PIX device, switched to multiple mode, and then searched for the priority-queue global configuration mode command. Notice that, sure enough, the command was not available in the CUSTA context, or the system context.
pixfirewall# configure terminal pixfirewall(config)# mode multiple WARNING: This command will change the behavior of the device WARNING: This command will initiate a Reboot Proceed with change mode? [confirm] Convert the system configuration? [confirm] pixfirewall> enable pixfirewall# show mode Security context mode: multiple pixfirewall# configure terminal pixfirewall(config)# context CUSTA Creating context 'CUSTA'... Done. (2) pixfirewall(config-ctx)# context CUSTA pixfirewall(config-ctx)# config-url flash:/custa.cfg pixfirewall(config-ctx)# allocate-interface e2 pixfirewall(config-ctx)# changeto context CUSTA pixfirewall/CUSTA(config)# pri? configure mode commands/options: privilege pixfirewall/CUSTA# changeto context system pixfirewall# conf t pixfirewall(config)# pr? configure mode commands/options: privilege
OK, so we have no QoS capabilities when in multiple context mode. What QoS capabilities do we possess on the PIX/ASA when we are behaving in single context mode? Here they are:
Policing – you will be able to set a “speed limit” for traffic on the PIX/ASA. The policer will discard any packets trying to exceed this rate. I always like to think of the Soup Guy on Seinfeld with this one – “NO BANDWIDTH FOR YOU!”
Shaping – again, this tool allows you to set a speed limit, but it is “kinder and gentler”. This tool will attempt to buffer traffic and send it later should the traffic exceed the shaped rate.
Priority Queuing – for traffic (like VoIP that rely hates delays and variable delays (jitter), the PIX/ASA does support priority queuing of that traffic. The documentation refers to this as a Low Latency Queuing (LLQ).
Now before we get too excited about these options for tools, we must understand that we are going to face some pretty big limitations with their usage compared to shaping, policing, and LLQ on a Cisco router. We will detail these limitations in future blogs on the specific tools, but here is an example. We might get very excited when we see LLQ in relation to the PIX/ASA, but it is certainly not the LLQ that we are accustomed to on a router. On a router, LLQ is really Class-Based Weighted Fair Queuing (CBWFQ) with the addition of strict Priority Queuing (PQ). On the PIX/ASA, we are just not going to have that type of granular control over many traffic forms. In fact, with the standard priority queuing approach on the PIX/ASA, there is a single LLQ for your priority traffic and all other traffic falls into a best effort queue.
If you have been around QoS for a while, you are going to be very excited about how we set these mechanisms up on the security appliance. We are going to use the Modular Quality of Service Command Line Interface (MQC) approach! The MQC was invented for CBWFQ on the routers, but now we are seeing it everywhere. In fact, on the security appliance it is termed the Modular Policy Framework. This is because it not only handles QoS configurations, but also traffic inspections (including deep packet inspections), and can be used to configure the Intrusion Prevention and Content Management Security Service Modules. Boy, the ole’ MQC sure has come a long way.
While you might be frustrated with some of the limitations in the individual tools, at least there are a couple of combinations that can feature the tools working together. Specificaly, you can:
Use standard priority queueing (for example for voice) and then police for all of the other traffic.
You can also use traffic shaping for all traffic in conjunction with hierarchical priority queuing for a subset of traffic. Again, in later blogs we will educate you more fully on each tool.
Thanks for reading and I hope you are looking forward to future blog entries on QoS with the ASA/PIX.
Hello all. I have had some peers ask me for help in getting up and running quickly with GNS3 to help master the PIX/ASA.
Here is my step-by-step on that.
I am installing on the following system:
Windows Vista Home Premium
AMD Athlon 64 X2 Dual Core Processor 5600+ 2.80 GHz
4 GB RAM
Notice I am running Vista (sigh). There is a lot of misinformation out there about GNS3 not working with Vista. This is not true, as you will read below.
I head up to www.gns3.net and download the WIN32-all-in-one EXE file available from the Download area. I run this EXE and proceed with the install. This is a “spousal” installation, just say YES (next) to everything the install wizard has to ask you.
In order to get ready to run my first emulations, I have created a folder called c:\Cisco Images and I have placed the following images there c3725-advsecurityk9-mz.124-15.T7.bin, pix723.bin, and pix724.bin. I should mention that for all of this I want to be logged in as a Vista Administrator.
I now launch GNS3 and perform the following:
Step 1: In the Setup Wizard dialog click the large 1 button.
Step 2: Click the Dynamips option in the left pane and click the Test button on the Dynamips tab to ensure that Dynamips can be found successfully.
Step 3: Click Pemu in the left pane and in the Defaults PIX settings area, click the …button and select your PIX image from your Cisco Images folder. In my case, this results in C:\Cisco Images\pix724.bin.
Step 4: Click the … button for Base Flash: and select your base flash image. In my case, this results in C:\Cisco Images\pix723.bin.
Step 5: Click OK in the Preferences dialog.
Step 6: Click the large 2 button.
Step 7: Under the Settings area, click the … button and choose your IOS image file from your Cisco Images folder.
Step 8: Choose Save and then Close from the IOS images and hypervisors dialog.
Step 9: Click OK in the Setup Wizard.
Step 10: In GNS3, drag your router model from the Nodes Type pane into the main topology pane. Right-click the router (R0) and choose Start.
Step 11: Right-click the router and choose Idle PC. Click OK in the IDLE PC dialog. Click OK in the next IDLE PC dialog.
Step 12: Drag the PIX firewall from the Nodes Type pane into the main topology pane. Right-click the firewall (FW0) and choose Start. NOTE: If your firewall fails to start with an error 209, it might be a Vista permissions issue. Close everything down. Right-click the file C:\Program Files\GNS3\pemuwrapper.exe and choose Run As Administrator. Then from the Start Menu, right-click GNS3 and choose Run As Administrator. You should be fine now.
Step 13: From the GNS3 toolbar, choose the Add a Link button. Click Manual. Click R0 and choose an interface and then click FW0 and choose an interface.
Step 14: You are now ready to configure your devices and start having some fun! Hover your mouse over a device you want to configure and notice the port number. Use your favorite terminal program (Terra Term, CRT, HyperTerminal) and connect to Localhost and that port number you just found.
This post was created using GNS3 and follows what I thought was some of the most lab and real-world relevant content from the Cisco ASA documentation in the area of IP Routing:
Here is the topology used:
First, we place the necessary IP configurations on the devices for our initial connectivity:
R0: en conf t host R0 line con 0 exec-time 0 0 logg synch ! int fa0/0 no shut ip address 192.168.1.100 255.255.255.0 end
R1: en conf t host R1 line con 0 exec-time 0 0 logg synch int fa0/0 no shut ip address 10.10.10.100 255.255.255.0 ! interface loopback 20 ip address 10.10.20.100 255.255.255.0 end
R2: en conf t host R2 line con 0 exec-time 0 0 logg synch int fa0/0 no shut ip address 172.16.1.100 255.255.255.0 end
FW0: en conf t host FW0 ! int e0 ip address 192.168.1.1 255.255.255.0 nameif outside no shut ! int e1 ip address 10.10.10.1 255.255.255.0 nameif inside no shut ! int e2 ip address 172.16.1.1 255.255.255.0 nameif DMZ security-level 50 no shut ! end
At this point, I will be sure to ping each connected router from the PIX to ensure IP connectivity. Remember, by default you can ping from the PIX and to the PIX, but you cannot ping through the PIX.
First, I will create a simple static route to the “remote” loopback network that I have created on R1. Notice that to create a static route we simply use the route command, followed by the interface name, then the network and mask, and finally the next hop. Notice how similar this is to the syntax for a static route on a router, although one major difference is the command does not begin with ip.
FW0: conf t route inside 10.10.20.0 255.255.255.0 10.10.10.100 end
Verification of this static route can be accomplished with a show route and a ping of the remote destination address 10.10.20.100.
Default Static Routing
In order to configure a default static route, use the route command but with an all 0′s network prefix and mask. The PIX/ASA allow a shortcut of 0 and 0 to represent 0.0.0.0 and 0.0.0.0. Here I configure a default static route pointing to our outside router.
FW0: conf t route outside 0 0 192.168.1.100 end
Verification for this configuration is a quick show route. The PIX/ASA should now show a gateway of last resort and the static route should be marked as a candidate default.
Static Route Tracking
An issue with the static route we just configured is the fact that if the destination gateway of last resort is down, the route is not removed from the routing table. This issue can be circumvented with the static route tracking capability.
First, I use the Cisco IOS IP Service Level Agreements (SLAs) monitor feature to track the availability of the gateway. This is done with the following commands:
FW0: conf t sla monitor 1 type echo protocol ipIcmpEcho 192.168.1.100 interface outside exit sla monitor schedule 1 life forever start-time now end
Notice these commands instruct the SLA monitor to ping the gateway starting now and to do this forever. I picked an SLA_ID of 1 to bind these commands together.
Next, I will associate a tracked static route with the SLA monitoring process using the following commands. Notice here that I have used a Track_ID of 20 and I have recreated our default static route so that it includes the Track_ID. Notice also here that the track command is tied to the SLA monitor with the SLA_ID of 1.
FW0: conf t track 20 rtr 1 reachability route outside 0 0 192.168.1.100 track 20 end
A nifty verification at this point is to move to R0 (the gateway of last resort) and run debug ip icmp. You will find that this router is being pinged every minute by the firewall now as a reachability test.
Next, I create a backup default static route. This is simply another default static route entry that possesses a higher administrative distance than the original static default route:
FW0: conf t route outside 0 0 192.168.1.55 22
For verification, you can shut the interface on the default gateway and run a show route on the PIX/ASA to ensure the backup is installed.
Dynamic Routing – OSPF
Now it is time to tackle a dynamic routing protocol configuration. Here I configure an MD5 authenticated neighborship between R2 and FW0. Notice that the network command on the PIX/ASA requires a subnet mask as opposed to a wildcard mask.
R2: conf t router ospf 1 network 172.16.1.100 0.0.0.0 area 0 ! interface fastethernet 0/0 ip ospf authentication message-digest ip ospf message-digest-key 1 md5 cisco ! end
FW0: conf t router ospf 1 network 172.16.1.1 255.255.255.255 area 0 ! interface e2 ospf authentication message-digest ospf message-digest-key 1 md5 cisco ! end
For verification, simply run show ospf neighbor on FW0.
Dynamic Routing – RIP version 2
Next, we will run RIP version 2 on the PIX/ASA and advertise the DMZ subnet to the internal router R1. Here are the configurations:
R1: conf t router rip version 2 no auto-summary passive-interface default network 10.0.0.0 no passive-interface fa0/0 end
FW0: conf t router rip version 2 no auto-summary network 172.16.0.0 network 10.0.0.0 end
Verification for RIP in this example would include show ip route on R1 and debug rip on FW0.
I certainly hope you have enjoyed this blog on IP routing with the PIX/ASA. While my goal was to hit the highlights, please keep in mind the fact that there are many features of the dynamic routing protocols that are available and not covered here. In fact, there are even some static routing features that were omitted in this discussion. Just remember that these features should be very easy to find in the documentation link when you are in the heat of battle.