Version 9.0 of the Cisco ASA software has now been released. Here are some of the major features in the new release.
- Filter ICMP by ICMP code
- Clustering of multiple ASAs
- OSPFv3 and EIGRP support
- IPv6 support on outside interface for VPNs
- NAT for IPv6 and NAT64
- DHCPv6 relay
- Unified ACLs for v4 and v6
- Clientless SSL VPN – Support for new browsers and HTML5
- Site to Site VPN in multiple context mode
- Dynamic routing in multiple context mode
- Mixed firewall support in multiple context mode
There seems to be some interesting features in here. If you are running v6
in your network this release seems much more useful. Also site to site VPNs
in multiple context mode is something that has been long overdue. It’s
also nice to see that you can run different firewall modes for each
It was rumored that 9.0 was supposed to have BGP. I don’t see this mentioned
anywhere. I’m not sure if it got delayed or if they abandoned the idea but
some people like to run BGP on their firewalls. In my opinion it’s better
to keep a router for that but it wouldn’t hurt to have the option of running
One thing that seems interesting is being able to cluster ASAs. I did not find
much information about this but it seems like the ASAs would be treated as
one logical unit. The difference to failover would be that you can use
the power of the multiple ASAs so if one ASA could inspect 100 Mbit/s you
should be able to inspect 200 Mbit/s with two of them. I’ll have to try
to find some more information on this feature.
Continuing to check things off from the blueprint. Did some ZBFW labbing today. Here are some important stuff to be aware of.
ZBFW is basically a wrapper for CBAC. We create policys between zones and assign interfaces to zones instead of applying CBAC rules to interfaces.
By default all traffic to the self zone will be allowed (router from and to router itself). If we apply policys to self zone then everything is dropped except for the traffic that is explicitly permitted. We need to be aware of this to not mess with the routing if we get such a task at the lab.
The self zone can only inspect TCP, UDP and ICMP but not protocols like telnet and SSH. To work around this we can do a class-map matching an ACL AND the protocol TCP if we are matching telnet traffic.
It’s not very intuitive to see which traffic is dropped. We can turn on logging with ip inspect log drop-pkt. This helps a lot to see which traffic is being dropped.
ZBFW is massive in configuration, you will be typing a lot. It is easy to get confused and mix things. Name things intuitively, name class-maps CM_INSIDE_PROTOCOLS, name policy-maps PM_INSIDE_TO_OUTSIDE or names similar to that. If you don’t you will easily get lost after a while due to the massive config.
Packet counters for ZBFW can’t be trusted, this seems to be due to a bug. Verify by pinging or telneting to create traffic.
Use Notepad when creating the config, it is faster and less prone to errors.
All traffic flows are unidirectional so we need to create zone pairs for both directions depending if we want traffic to flow both ways.
We can have three different actions for traffic in the policy-maps.
Pass – Traffic gets through but not return traffic is permitted. Useful for “stateless” protocols like RIP
Inspect – Allow traffic through and also allow the return traffic back.
Drop – Drop the traffic
If we have a policy-map that allows some traffic through, the rest of the traffic not matching any class will be implicitly dropped, this is even if we don’t specify a class class-default.
That are the most important things you need to be aware of when configuring this feature.
To enable AAA we need the AAA new-model command but what does it really do? Many of us makes assumptions about this command.
By default if we have an empty config then we will be able to use the console and get straight into enable mode (priv15). If we try to telnet in (VTY) then we can’t login since no password has been set. If we set a password then we can login to priv 1 but we won’t be able to enable since no enable password has been set.
When configuring AAA we use method lists. We can use the list called ‘default’ or create our own. The sneaky thing about aaa new-model is that when we enable this the ‘default’ list goes active which is applied to the VTY. What surprised me is that this is not applied to the console. Someone had a theory that Cisco wanted to apply it to both console and VTY but too many users got locked out of their routers so they had to back on this implementation, true or not, I don’t know.
When aaa new-model has been enabled the device will ask for local authentication. If we haven’t defined any users then no access for you (VTY-nazi). Console will still work though, we will have to enable to enter priv 15 as usual.
Now if we define a user we will be able to login remotely as well, we do need to configure an enable password to get into priv 15 though.
For the lab I have seen that if people get a task with AAA they will create a new method list with no authentication and no authorization and apply it to the console and VTY. As I pointed out we should not have to enable this to the console but better safe than sorry I guess. This can be configured in the following way:
aaa authentication login VTY none
aaa authorization exec VTY non
line con 0
login authentication VTY
authorization exec VTY
line vty 0 4
line authentication VTY
authorization exec VTY
How would you configure this, what do you do in real life? Post in comments.
I’m going through the blueprint and now I checked off IP accounting. The feature is very simple, it lets us see which source destination pairs that are sending traffic to each other. We can also configure to look what precedence values that are in the packets. There is also an option to look at the MAC-addresses of the packets passing through and also packets that are being denied by an access-list. The topology is dead simple, see below.
Configure your routing protocol of choice to get reachability. I’m using OSPF, it does not matter at all as long as you have connectivity. Now lets say that we are interested in which source and destination pairs that are sending traffic THROUGH the router (transit). Packets destined TO the router will not be seen in the accounting. I’ll configure accounting on R2′s interface to R1 and then initiate a ping from R1 to R3. I’ll send traffic both to the loopback and R3′s FastEthernet interface to see two different source/destination pairs.
OK, lets ping.
Now we will check the accounting database with the show ip accounting command.
So that shows us what sources/destinations are sending traffic to each other, interesting! We can also see the number of packets and number of bytes. If we want to check statistics for only certain hosts we can use the global ip accounting-list command to define what hosts we are interested in. We define hosts/networks as in ACL with network/wilcard combination.
Storing entries in the IP accounting database requires some memory, there could be a risk of exhaustion if we have too many entries but the default is set to max 512 entries. We can define this with the global ip accounting-threshold command.
So now we want to check what IP precedence values pass through our interfaces and also what MAC addresses that are sending/receiving traffic. Lets configure this.
Then we send some pings from R1, I will send with a ToS of 128, what IP precedence/DSCP is that? Think quick.
Lets verify at R2 if we see anything, the command to use is show interface precedence.
So a ToS of 128 was a IP prec of 4 but you already figured that, right? What is that traffic with IP prec 6? Mysterious…We are running routing so that is OSPF which is marked with an IP precedence of 6 automatically by the router itself. We can also check what MAC addresses have been learned.
Here we also see OSPF represented by the MAC address 01-00-5E-00-00-05. We can also see when the last packet was sent which is quite handy. Now we will turn on accounting for access-lists as well, first we will define an ACL denying ICMP to 220.127.116.11 which is the loopback of R3. Note that we need the log keyword in the ACL.
Now we send traffic from R1 to 18.104.22.168.
For some reason I don’t see anything with the show ip accounting access-violations. Maybe this is a software issue? I tried turning off CEF as well. If any of my readers get this working I would be interested.
Lastly lets have a brief look at how traceroute works in IOS. Cisco devices uses UDP traceroute compared to ICMP used by Windows. The router sends packets with TTL of 1 and then N+1 the further away the probe goes. Traceroute sends three packets for every hop. The first hop will have a destination port of 33435, the second one will have 33436 and so on. If we want a router to not respond to traceroute we can turn off IP unreachables. Note that this will not hinder traceroute for which this router is not the final destination. Only the final device will send an ICMP unreachable (port unreachable) which is ICMP code 3. The other routers will send time exceeded which is ICMP code 11.
If we did want to block traceroute going through the router we could block this with an ACL denying packets that have ttl-exceeded or all packets lower than a certain TTL. If we need to find ICMP codes we can reference the ASA library. This should be available at the lab. You can find the reference by following this path.
Products > Security > Firewalls > Firewall Appliances > Cisco ASA 5500 Series Adaptive Security Appliances > Configure > Configuration Guides > Cisco ASA 5500 Series Configuration Guide using the CLI, 8.4 > Reference > Addresses, Protocols, and Ports > ICMP types
So this is just another feature that is handy to have.
I found a very useful tool when practicing the INE labs. How to generate
traffic with traceroute. I’ve used telnet lots of times to generate TCP
traffic on different ports but what if we want to generate UDP traffic instead?
We can used traceroute to our advantage.
The topology is the one I’ve been using for my last posts with two routers
connected by a FastEthernet link.
First we create an access-list on R1 that will deny UDP on ports 9 and 19
but allow everything else.
We will confirm connectivity by doing a ping and then a telnet.
The traffic is passing successfully. Lets check the access-list on R1.
We have matches in the ACL, now lets generate traffic with traceroute.
We will type traceroute and then enter the options.
The important thing here is of course to change the port to something else
than the default port 33434. You can see by the !A in the answer that the
traffic was prohibited. Lets confirm this with looking at the ACL on R1.
And that is how you generate traffic with traceroute. Combined with the telnet
tool we can pretty much simulate most of TCP or UDP traffic. This gives us an
advantage in the lab so that we may test our ACLs to see that they are working
The lock and key ACL is one of those features you’re not sure how to use in
production but it is viable for the CCIE lab. The lock and key ACL is a form of dynamic
ACL which requires a key before unlocking access. The lock and key ACL can only
have one dynamic entry per ACL.
We will be looking at a very simple topology with 3 routers. R2 will act as a
firewall for traffic coming from R1 going to R3. We will create an ACL that
denies telnet to R3′s loopback but allows everything else. We will run OSPF for
reachability but configuring it is out of scope for this post.
This is the topology.
All 3 routers have been configured with transit links and a
loopback address of 22.214.171.124, 126.96.36.199 or 188.8.131.52. All the magic
will occur on R2.
First we verify that we have reachability from R1 to R3 through
ICMP and telnet.
Reachability is good. Now we will start configuring the dynamic ACL on R2.
Lets try if we can telnet from R1.
As expected we can telnet to the Fa0/0 interface but not the loopback.
Now we need to create an user on R2 that will unlock the dynamic
ACE on R2. We also need to use the autocommand feature.
Now we have created the user and enabled the autocommand feature.
The autocommand will execute a command when the user logs in. The
enable-access feature is used to activate they dynamic ACE in the ACL.
We also need to enable local login on the VTY lines on R2.
Now we will login to R2 from R1 and see if we can telnet to R3.
After authenticating we get kicked out and the ACE has now been activated. We can now
telnet to R3′s loopback.
Lets look at the ACL on R2.
You can see that there is a dynamic entry allowing us to telnet to the loopback of R3.
So summarizing lock and key is a cool feature that is not very usable in real life but a
good tool to have on your lab exam.
You can download the configs, both initial and final and the .net file from here.
Don’t forget to set image dir and working dir.
This post describes how to filter packets with a route-map. I have never used
a route-map for the sole purpose of filtering packets before. I ran into this
while doing a vol2 lab and the task was to filter ICMP packets coming in
on a frame-relay interface and out on VLAN 162. The packets should only
be filtered if they were between 100 and 200 bytes long. The topology is
the same as in my previous post.
My first thought was to use MQC to accomplish this but we were not allowed
to do so. We were not allowed to use FPM either. That only leaves us with
a route-map. Often policy routing is not allowed in the CCIE lab unless
specified but in this case it is our only option.
First we create an ACL that matches all ICMP. All configuration is applied to R6.
Then we create the route-map and do some matches.
The packets have to match all three criterias. The packet must match the ACL ICMP
which means it’s an ICMP packet. The packet is between 100 and 200 bytes long. The
packet is being output on interface FastEthernet 0/0 meaning the VLAN 162 subnet.
We apply the policy to the S0/0/0.1 interface which is the frame-relay interface.
Remember that traffic destined to the router is not affected by this policy, only
transit traffic will be affected. This means that packets won’t be dropped if we
try to ping R6.
Lets confirm that the policy is working. We turn on policy debugging on R6.
The testing is done from BB1. You can see that when the packets are only 50 bytes long
there is no dropping ocurring. If we use a size of 150 bytes packets are being dropped.
The policy is working, lets look at debug output on R6.
The first five packets don’t match the policy so they use normal forwarding. The next five
packets are being dropped. We can also see this with show route-map.
And this is how flexible route-maps are, we can use them to modify metrics, redistribute and
even filter traffic.
While doing a vol2 lab I got stumped by one of the tasks in the lab.
The task was to filter ICMP packets coming from the backbone destined
to a network on the internal routers. The topology looks like this.
We need to filter ICMP packets from BB2 but we may not apply this on
R1 and/or R6. We are of course not allowed to do any changes in the
backbone either. So what is left? We have an Ethernet segment connecting
the routers together, they are all connected to a switch. This means
that we can apply a VLAN filter. VLAN filters are good for filtering
traffic that does not leave the VLAN. For traffic crossing network
boundaries we can use regular ACL’s but they won’t work for intra VLAN
The configuration is pretty straight forward and has a lot of resemblance
to a route-map. First we create a VLAN access-map.
We want to drop traffic when there is a match in access-list 100. If there is
not a match permit the traffic.
Then we create the access-list.
The 184.108.40.206/24 network is one of the backbone networks but the addressing is
not what’s important here.
Then we need to apply the filter to the VLANs that should be filtered.
We have a few show commands that will show us what filters are in use.
In this configuration we permitted the traffic that should be dropped in an ACL. Could we
have done the reverse? An alternate solution is to make an action of forward and then
deny the ICMP traffic. Lets look at this.
The logic is reversed here. We forward only certain traffic and drop the rest. We also
need to modify ACL 100.
ICMP from 220.127.116.11 will be denied and all IP allowed, should work like a charm right?
And it might, for a while… There’s a pitfall in this configuration, we have allowed
all IP but there is one other quite important protocol used in Ethernet segments. We
use it when we know the IP address of a host but need to find out the MAC address. Yes,
it is ARP. With this ACL all ARP will be dropped. Some traffic might go through due to
that we have entries in the cache but as soon as they time out there will be a problem.
If we need to allow ARP we can do that by creating a MAC access-list.
So now you know how to filter traffic within a VLAN. There is almost always more than
one solution but we need to be careful when thinking through alternate solutions.
Reflexive access-lists is a way of filtering traffic where only return traffic
is allowed if it belongs to a session initiated on the “inside”. In a regular
access-list we can use the keyword established for filtering but that only
looks at if the TCP flag ACK has been set which is the case for all packets
except the first one in a session. This isn’t really stateful filtering.
We will use a very simple topology with three routers, diagram is below.
The objective is to allow all TCP from R3 to R1. R1 should be able to use ping
and traceroute and to establish routing peerings with R2.
If you want to try this lab yourself you can download topology, initial configs
and final configs from here.
Lets start by doing a telnet from R3 to R1 and reverse just to see that we have
reachability and that nothing is being filtered.
Everything working as expected. Now lets start creating access-lists. We will
be filtering on R2 Fa0/0. Traffic from R3 to R1 will be outbound and traffic
from R1 to R3 will be inbound.
The keyword here is reflect, we need to match MYREFLECT on the inbound ACL to make
it reflexive. If we want to add more statements like UDP we can do that but
remember to use the reflect keyword.
Now we create the inbound ACL.
We need to explicitally allow ICMP since ICMP is not stateful. We also need
to allow routing because the traffic is terminated on the router.
Apply ACL to R2 Fa0/0.
If our configuration is correct telnet from R3 to R1 should work but not
the other way around.
Still working. We can also see matches in the ACL.
Now lets try from R1 to R3.
That was denied. Are we still able to ping R1 from R3?
There is also matches in the ACL.
Traceroute from R1.
Can R1 form an EIRGP peering?
So reflexive access-lists can be a very useful feature. If you have
a lab task that says that only traffic initiated from inside should
be allowed back in it’s a good bet to use reflexive access-lists.
If you download the .net file remember to set the IOS image dir and your working dir.