CCNA and Beyond: Packet Tracer files download

I have been asked to provide the lab files in Packet Tracer format.

Whilst I would strongly advise using a platform such as UNetLab, it's been asked for, so I feel it should be provided.

The config lab files are over in the forum, and I will be adding the troubleshooting section PT files in due course.

There is a mapping of the interfaces referenced in the book (which was written with UNetLab in mind) to the interfaces used in Packet Tracer.

Enjoy and happy studying!

Stuart.

CCNA v3.0: Describe the impact of firewalls in an Enterprise Network (Part 2)

In part 1, we saw the effect of putting a firewall into an enterprise network. If you have not read that post then please read it before reading this one, otherwise somethings may not make sense. In the post we saw that we can go from higher-level interfaces to lower, but not from lower to higher, and this is all about the trust we put in our zones.

In this part, we will add a DMZ to our network, and explain why we do this. We will also fix the network so that the Internet router can telnet into our network, but will be confined to the DMZ. Before we do this though, let's go back to a little theory and discuss the difference between stateful and stateless firewalls.

Stateful vs. Stateless firewalls

Our ASA is a stateful firewall. Stateful firewalls keep a connections table, and this is the users traffic. We can look at the traffic in a number of ways, just on the source and destination (layer-3), or we can go all the way up to layer-7 and include the protocol, and the ports being used.

Stateless firewalls (which were the first type of firewall) just perform packet filtering, and are more like extended access lists. There is less intelligence with stateless firewalls. Each request is treated separately to the response. So we need to be much more careful with stateless firewalls, and make sure that for each outgoing ACL (Access List), we have one to allow the return traffic, instead of the stateful firewall, which adds more intelligence, and will dynamically allow the return traffic, if the return traffic is part of an existing outgoing connection.

We saw this in the previous post, where we could telnet from Inside-1 to the Internet router, and the connection was set up, the return traffic was allowed through because of the stateful nature of the firewall. The firewall could see that the outgoing connection was set up, and the response was matched to this connection entry.

Before we added NAT, we could allowed the incoming telnet connection (originating from the Internet router), because we knew exactly who Inside-1 was. We then implemented NAT, which hid Inside-1 behind the external IP address of the ASA (10.1.1.2). Now, with NAT, the Internet router will not be able to telnet directly to the Inside-1 router, as the ASA will not know to which host the traffic is destined for. For this to work we would need to add another NAT rule, giving Inside-1 an external address, which can then be used by the ASA to correctly direct the traffic. However, this is really not the best design. Incoming connections should be directed to a DMZ (Demilitarized Zone), which adds another level of security to the network. So let's do this now.

DMZs

DMZs allow us to accept incoming connections, but keep them separated from our LAN.  These get their own security level (0 by default, like the Outside). If we add this to our network, it starts to look like this:

We have another router hanging off the ASA, and this will get a security level of 0, as we can see if we set it up:

ASA(config)# int gi0/2
ASA(config-if)# ip add 172.16.1.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# nameif DMZ
INFO: Security level for "DMZ" set to 0 by default.
ASA(config-if)# security-level 50
ASA(config-if)# 

DMZ(config)#int gi 0/0
DMZ(config-if)#ip add 172.16.1.10 255.255.255.0
DMZ(config-if)#no shut
DMZ(config-if)#exit
DMZ(config)#ip route 0.0.0.0 0.0.0.0 172.16.1.1
DMZ(config)#end
DMZ#ping 172.16.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.16.1.1, timeout is 2 seconds:
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 2/2/3 ms
DMZ#

Notice that I have set a security level of 50. Security levels are all about trust. Our internal network got a security level of 100 (we trust it a lot), the Internet got a security level of 0 (we really don't trust it), but we do trust the DMZ, just not as much as the internal network, so we can set it to 50.

The next step is to allow the Internet router to telnet to the DMZ router. To do this we need to add another NAT rule to forward traffic from an address in the 10.1.1.0/24 network (10.1.1.100), to the DMZ router (172.16.1.10), and permit the traffic:

ASA(config)# object network obj-DMZ 
ASA(config-network-object)# host 172.16.1.10
ASA(config-network-object)# exit                                         
ASA(config)#
ASA(config)# object network obj-DMZ-External
ASA(config-network-object)# host 10.1.1.100
ASA(config-network-object)# exit
ASA(config)#
ASA(config)# nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External 
ASA(config)# 

Notice that I have not actually added an ACL to permit this traffic. This is because we actually added one that permits this traffic in the previous post:

ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet
ASA(config)# 

As such we do not need to add one to permit traffic coming from the outside to the DMZ. But we did need to add the NAT rule. For more information on NAT, pick up the CCNA and Beyond study guide from Amazon, there are a lot of NAT exercises in there.

We can see that this works by telnetting from the Internet router to the IP address 10.1.1.100, and we can also see the hit count on the ASAs ACL increase:

Internet#telnet 10.1.1.100
Trying 10.1.1.100 ... Open


User Access Verification

Password: 

DMZ>exit

[Connection to 10.1.1.100 closed by foreign host]
Internet#

ASA# sh access-list outside->in
access-list outside->in; 2 elements; name hash: 0x307dc218
access-list outside->in line 1 extended permit icmp any any (hitcnt=0) 0x6d9415b4 
access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=2) 0x95b68c2a 
ASA# 

Returning to the NAT rule we set up, instead of referencing IP addresses, we used objects.

Firewall objects

Working with objects makes life much easier. We can group related services (such as HTTP and HTTPS) into one object (such as calling it "WEB-Traffic"):

ASA(config)# object service WEB-Traffic
ASA(config-service-object)# service tcp destination eq http
ASA(config-service-object)# service tcp destination eq https
ASA(config-service-object)# 

We can now reference this in our NAT or ACL statements, and this makes reading the configuration much easier (and keeps things cleaner). The downside to this is that it becomes harder to match ACL hits to an individual endpoint. If you have ten hosts within an object and a thousand hits on the ACL, it's hard to see which of these hosts are actually receiving the traffic. But this is just one of those things that you learn from as you go.

NAT order of operations

Before we leave this post we should return to a bit of theory, and look at the order of operations that a Firewall goes through as traffic comes in, or goes out.

The actual order of events is fairly similar, but changes depending on the direction of the traffic.

The Cisco doc here, outlines all the steps taken. We can test this within the ASA itself though, using the packet-tracer command (I have truncated the output a bit to make it a little more readable):

ASA# packet-tracer input inside tcp 192.168.1.10 telnet 10.1.1.1 telnet detailed

Phase: 1
Type: ROUTE-LOOKUP
Subtype: Resolve Egress Interface
Result: ALLOW
Config:
Additional Information:
found next-hop 10.1.1.1 using egress ifc  Outside

Phase: 2
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:
Dynamic translate 192.168.1.10/23 to 10.1.1.2/23
 Forward Flow based lookup yields rule:
        input_ifc=Inside, output_ifc=Outside

Phase: 3      
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (Inside,Outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
Additional Information:

Phase: 7
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 8
Type: NAT
Subtype: per-session
Result: ALLOW 
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 9
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:
        input_ifc=Outside, output_ifc=any

Phase: 10     
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:

Module information for reverse flow ...

Result:
input-interface: Inside
input-status: up
input-line-status: up
output-interface: Outside
output-status: up
output-line-status: up
Action: allow

ASA# 

The above is for traffic leaving the network, going from 192.168.1.10 to 1.1.1.1. In Phase 1, we look to see if we have a route to the destination, and this gives us our "egress" interface. In Phase 2, we perform NAT, mapping our inside subnets to our external interface's IP address (10.1.1.2). Because the type of NAT we are using is PAT (and again pick up CCNA and Beyond to understand more about PAT), this is setup and allowed in Phase 4. Phase 5 passes, because we have not implemented QoS (Quality of Service). Phase 6 is an additional check, called Reverse Path Forwarding, which means that we check to make sure that the reply to the traffic is going to come back through the interface we sent the original request out of. This helps eliminate routing loops, and general traffic weirdness. We have more QoS in Phase 7, which again passes, and we move on to Phase 8. Here we again set up NAT, but for the return traffic, you can tell this because it is for the "Reverse Flow". We have not set any IP options, so Phase 9 passes, and we move on to Phase 10. Here the flow is created, and we see that everything has worked.

Let's look at traffic coming in now.

ASA# packet-tracer input outside tcp 10.1.1.1 telnet 10.1.1.100 telnet detailed

Phase: 1
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
NAT divert to egress interface DMZ
Untranslate 10.1.1.100/23 to 172.16.1.10/23

Phase: 2
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group outside->in in interface Outside
access-list outside->in extended permit tcp host 10.1.1.1 any eq telnet 
Additional Information:

Phase: 3
Type: NAT
Subtype: 
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
Static translate 10.1.1.1/23 to 10.1.1.1/23

Phase: 4
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type: QOS
Subtype: 
Result: ALLOW 
Config:
Additional Information:

Phase: 7
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
nat (DMZ,Outside) source static obj-DMZ obj-DMZ-External
Additional Information:
 Forward Flow based lookup yields rule:
 out id=0x7fb295a33350, priority=6, domain=nat-reverse, deny=false
        dst ip/id=172.16.1.10, mask=255.255.255.255, port=0, tag=any, dscp=0x0
        input_ifc=Outside, output_ifc=DMZ
              
Phase: 8
Type: QOS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 9
Type: NAT
Subtype: per-session
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 10
Type: IP-OPTIONS
Subtype: 
Result: ALLOW
Config:
Additional Information:
 Reverse Flow based lookup yields rule:

Phase: 11
Type: FLOW-CREATION
Subtype: 
Result: ALLOW
Config:
Additional Information:
New flow created with id 41, packet dispatched to next module
Module information for forward flow ...

Module information for reverse flow ...

Result:
input-interface: Outside
input-status: up
input-line-status: up
output-interface: DMZ
output-status: up
output-line-status: up
Action: allow

ASA# 

The first step is to work out where the traffic is really supposed to go to, so in Phase 1 we un-translate 10.1.1.100 to 172.16.1.10. We then confirm that the traffic is permitted, and find a matching ACL in Phase 2. In Phase 3 we see that we are not doing any translation (or un-translation) on the source address of 10.1.1.1. In Phase 4 we allow the NAT, and again in Phase 5 and 6, because we do not have any IP options or QoS, the traffic is allowed. We again make sure that the traffic going out will match the interface that it came in on, by performing an RPF-check in Phase 7. In Phase 8 we pass the QoS, and in Phase 9 we set up the per-session NAT. Phase 10 passes because we have not set any IP Options, and in Phase 11 the flow is created.

So here you can see the difference between incoming and outgoing traffic, where NAT is concerned.

Whilst most of this is probably beyond the needs of the CCNA exam, this is the kind of skills you should pick up as you study. It will certainly help solidify knowledge of other areas.

In the next section of this series we will discuss the different modes a firewall can be in, and these are routed (as we have seen here), transparent, and multi-context.

CCNA v3.0: Describe the impact of firewalls in an Enterprise Network (Part 1)

The CCNA v3.0 added a new topic; to describe the impact of firewalls, access points and wireless controllers in an Enterprise Network.

We will start by looking at firewalls today, and over a couple of posts, because there is a lot to them. Don't worry too much though as the exam syllabus lists this as a "describe", rather than a "configure". So there will only be a couple of questions on these in the exam.

We will cover access-points and wireless controllers together in a separate post (as it makes sense to do that).

What is a Firewall?

A firewall can be either software-based, or hardware-based, but pretty much all of them are based around a Linux kernel. No matter what the make or model, they all do pretty much the same thing, and that is to separate the host machine, or network, into zones.

Zones allow us to segregate the network into different security areas. We will be concentrating on the syntax for ASA firewalls, mainly, as these are Cisco devices, and so will probably be the main focus in the v3.0 CCNA exam.

You can try the ASA out on Packet Tracer, but these are the 5505 ones (so really down at the small-end of the scale), and the software version is really old. You are much better off, of you really want to play around with firewalls, by looking at UNetLab, or GNS3.

With the ASA we can assign names to an interface, the most common being "Outside", "Inside" and "DMZ". We will first look at the Outside and the Inside.

We can have more than one "Outside", if we have multiple connections to the Internet. The Outside is given a security level value, which is 0 by default. Our Inside interface will also be given a security level value, usually this is 100.

By default we can go from a higher level to a lower level, but not from lower to higher.

Once we set up a firewall, we will see this in action, but the important thing to note is that we will be able to get from the inside network to the Internet, but the Internet would not be able to get into us. Firewalls are stateful, meaning it knows what traffic is leaving it, and will allow the return traffic, but this also means that, without some specific rules, traffic cannot get in.

So, let's see this in action. This is our existing network:

We have OSPF running through the network, and the Inside routers can reach the Internet (8.8.8.8):

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Inside-1#

Inside-2#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms
Inside-2#

The Internet can also reach the inside:

Internet#ping 192.168.1.10
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.10, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 4/4/5 ms
Internet#

Clearly, this is not very secure. So, we will look at the impact of firewalls in an Enterprise Network, by swapping the Gateway router for an ASA, which gives us a network that looks more like this:

First of all, we will set up our basic IP address:

ASA(config)# int gi0/1
ASA(config-if)# ip add 192.168.1.1 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# 

Can we reach this from Inside-1?

Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#

No, we cannot. Let's assign the interface to the "Inside" zone, and see if that helps:

ASA(config-if)# nameif Inside
INFO: Security level for "Inside" set to 100 by default.
ASA(config-if)# 

Inside-1#ping 192.168.1.1
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 3/6/12 ms
Inside-1#

So, now we have some measure of success, we can ping from Inside-1 to our ASA. We still cannot get any further, as we have not configured our Outside interface. Let's add this in:

ASA(config-if)# exit
ASA(config)# int gi0/0
ASA(config-if)# ip add 10.1.1.2 255.255.255.0
ASA(config-if)# no shut
ASA(config-if)# nameif Outside
INFO: Security level for "Outside" set to 0 by default.
ASA(config-if)# 

Instead of OSPF, we will set up some basic static routes for the moment:

Inside-1(config)#ip route 0.0.0.0 0.0.0.0 192.168.1.1
Inside-1(config)#

ASA(config-if)# route Outside 8.8.8.8 255.255.255.255 10.1.1.1
ASA(config)#end
ASA# ping Outside 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/10 ms
ASA#

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#

Now we can ping 8.8.8.8 from the ASA, but not from a host on the Inside. The Internet does not know about the 192.168.1.0/24 network.

With our Inside and Outside interfaces assigned, our network, logically, now looks like this:

Before we put the ASA in the network, we had full reachability between the Inside-1 and -2 routers and the Internet. We did this through OSPF, and the ASA is no exception - we can set up OSPF on our ASA:

ASA(config)# router ospf 1
ASA(config-router)# router-id 2.2.2.2
ASA(config-router)# network 0.0.0.0 0.0.0.0 a 0
ASA(config-router)# 

The adjacencies form, and the Internet can see the 192.168.1.0/24 network, and the Inside routers can see the 8.8.8.8 network, we just can't reach it:

Internet#sh ip route ospf | b Gate
Gateway of last resort is not set

O     192.168.1.0/24 [110/11] via 10.1.1.2, 00:03:53, GigabitEthernet0/0
Internet#

Inside-1#sh ip route ospf | b Gate
Gateway of last resort is not set

      8.0.0.0/32 is subnetted, 1 subnets
O        8.8.8.8 [110/12] via 192.168.1.1, 00:00:09, GigabitEthernet0/0
      10.0.0.0/24 is subnetted, 1 subnets
O        10.1.1.0 [110/11] via 192.168.1.1, 00:23:32, GigabitEthernet0/0
Inside-1#
Inside-1#ping 8.8.8.8             
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)
Inside-1#

Internet#
*May 29 14:54:10.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:12.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:14.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:16.377: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
*May 29 14:54:18.376: ICMP: echo reply sent, src 8.8.8.8, dst 192.168.1.10, topology BASE, dscp 0 topoid 0
Internet#

The logs above do show that the Internet is sending the reply back to the Inside-1 router. But it is not reaching it, because the return traffic is not permitted by the firewall. We need an access-list (ACL) to permit this.

Firewalls have Access-lists

We will start our access-list by permitting ICMP traffic:

ASA(config)# access-list outside->in extended permit icmp any any
ASA(config)# access-group outside->in in interface Outside
ASA(config)# 

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 7/10/13 ms
Inside-1#

We can now reach the Internet from Inside-1, because we allowed ICMP (which is the protocol used by ping) to come back into the network. We can also telnet from Inside-1 to the Internet (because we are going from a higher-level interface to a lower-level interface):

Inside-1#telnet 8.8.8.8
Trying 8.8.8.8 ... Open

User Access Verification

Password: 
Internet>
Internet>exit

[Connection to 8.8.8.8 closed by foreign host]
Inside-1#

Our Telnet source port will be one of the higher ports, to the destination port of 23, but the return traffic will be allowed because we have a stateful firewall, therefore because the traffic is initiated from the Inside, the return traffic will be permitted. What we cannot do is initiate a connection from the Internet, to Inside-1:

Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... 
% Connection timed out; remote host not responding

Internet#

We can amend our ACL to permit this traffic:

ASA(config)# access-list outside->in permit tcp host 10.1.1.1 any eq telnet
ASA(config)# 

Internet#telnet 192.168.1.10
Trying 192.168.1.10 ... Open

User Access Verification

Password: 

Inside-1>
Inside-1>exit

[Connection to 192.168.1.10 closed by foreign host]
Internet#

The 10.1.1.1 address is the source address on the Internet router, and "any" means any host on the Inside of our network. Until we added this last ACL rule, we were not explicitly denying the telnet traffic, but it was still denied. This is because ACLs have a default deny rule at the end of them, therefore any traffic that is not explicitly permitted, will be denied, by the implicit deny rule. It is implicit because it does not show up in the configuration:

ASA# show access-list 
access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096)
            alert-interval 300
access-list outside->in; 2 elements; name hash: 0x307dc218
access-list outside->in line 1 extended permit icmp any any (hitcnt=1) 0x6d9415b4 
access-list outside->in line 2 extended permit tcp host 10.1.1.1 any eq telnet (hitcnt=1) 0x95b68c2a 
ASA# 

As you can see here, we have the two rules we added, but there is no rule stating that other traffic is to be denied, the rule exists, but we just can't see it, because it is implicit.

Firewalls and NAT.

Strictly speaking, we wouldn't be running OSPF straight from the ISP into our network. The RFC1918 addresses we use on our internal network are not routable on the Internet, and if you were to advertise a default route to the ISP, well, I am sure they would not be happy about it.

Therefore we will hide our network behind Network Address Translation (NAT):

ASA(config)# object-group network INSIDE-NAT-SUBNETS
ASA(config-network-object-group)# network-object 192.168.1.0 255.255.255.0
ASA(config-network-object-group)# exit
ASA(config)# nat (inside,outside) after-auto source dynamic INSIDE-NAT-SUBNETS interface
ASA(config)# 

Can we still reach the Internet?

Inside-1#ping 8.8.8.8
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 8.8.8.8, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 10/11/13 ms
Inside-1#

Internet#
*May 29 15:27:23.020: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.032: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.044: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.057: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
*May 29 15:27:23.070: ICMP: echo reply sent, src 8.8.8.8, dst 10.1.1.2, topology BASE, dscp 0 topoid 0
Internet#

We can, but now we are hidden behind the firewalls outside interface (10.1.1.2).

The takeaway from this post is that you cannot just run out, buy a firewall, plug it in, and expect it to work. At the very minimum you will need to add some access lists, and remember the default deny rule. You should always NAT your traffic as well. Because of the NAT we will not be able to telnet from the Internet router to 192.168.1.10, but we will look at how to fix this in the next part.

In the second part of this post we will also look at the role of the DMZ (Demilitarised Zone), and in the third part, we will look at the different modes a firewall can be in. So far we have been looking at a routed firewall (it has a layer-3 IP address). This is just one flavour of firewall, but is the most common, certainly the one you are most likely to encounter.

Quiz time: A game of numbers

I have made a little quiz. It is just over 30 questions, and it's all about numbers in networking.

It is scored at the end, so you can try as many times as you like!

I will be doing more of these, some will be easier, some will be harder.

I hope you enjoy it.

Quizzes by Quibblo.com

5 things Cisco Packet Tracer WONT teach you (but you should know).

In this post I am going to have a bit of a moan about some of the things that the Cisco Packet Tracer (PT) does not support. I am sure that this post is just the tip of the iceberg!

I have not touched PT since my CCNA days, but now, several years on, I am going back to it to have a look. This is more of a fact finding mission, expect updates as I play with it a bit more.

The version I am using is 6.3.0.0009:

So, interface-wise, nothing seems to have changed that much since I used it last time. The layout is still the same, its all very drag and drop. We have a couple of different device options, such as the 1841 and 1941 routers, the 3560 switch and the ASA, which brings us to our first problem:

1: Packet Tracer does not support new IOSes

The versions on here are OLD!

Switch   Ports  Model              SW Version              SW Image
------   -----  -----              ----------              ----------
*    1   26     WS-C3560-24PS      12.2(37)SE1             C3560-ADVIPSERVICESK

ciscoasa#sh ver

Cisco Adaptive Security Appliance Software Version 8.4(2)
Device Manager Version 6.4(5)

Router(config-if)#do sh ver
Cisco IOS Software, C1900 Software (C1900-UNIVERSALK9-M), Version 15.1(4)M4,

You do not have the option to add new versions to PT. It's very limiting! You can't run Qemu nodes, and the ASA is very out-dated (and it's a 5505 which are right the the bottom end of the scale).

Anyway, how do we know what versions we are running? Well, you would usually look at the version (show version), but if you just want to get the information, and not the waffle, you would use the pipe command to include just the version, which brings us onto point #2.

2: No piping commands!

The really sucks, you can't use the pipe command to get just the information you need!

Switch(config)#do sh ver | i Version
sh ver | i Version
       ^
% Invalid input detected at '^' marker.
 
Switch(config)#

I want to be able to truncate the information I get to just the stuff I need, like finding the configuration for a particular interface.

3: You can't sh run interface

You have to look through the entire configuration to find the details for a particular interface:

Switch#sh run int fa0/24
              ^
% Invalid input detected at '^' marker.
 
Switch#sh run ?
  <cr>
Switch#sh run interface fa0/24
              ^
% Invalid input detected at '^' marker.
 
Switch#sh run ?
  <cr>
Switch#sh run 

Keep pressing that space bar to continue! This is not an efficient use of your time, and certainly as you progress from CCNA into a network career, and start looking towards the CCNP and CCIE, you will need to now how to get to the information you need as quickly as possible! You can't spend your time searching through the configuration to find the information you need.

Let's press on a look for something a little more advanced in the switching and routing domains.

4: MST

Switch(config)#spanning-tree mode ?
  pvst        Per-Vlan spanning tree mode
  rapid-pvst  Per-Vlan rapid spanning tree mode
Switch(config)#spanning-tree mode

No Multiple Spanning-Tree. I suppose this is OK, because it's not on the CCNA. But External BGP made it into the new v3.0, so how well is BGP supported?

5: No Internal BGP (iBGP)

Router(config-if)#ip add 1.1.1.1 255.255.255.255
Router(config-if)#router bgp 10
Router(config-router)#bgp router-id 1.1.1.1
Router(config-router)#neighbor 2.2.2.2 remote-as 10
Router(config-router)#
%Packet Tracer does not support internal BGP in this version. Only external neighbors are supported.


Router(config-router)#

Seriously? Oh, come on! How hard is it to have internal BGP working as well as external BGP? That's just plain lazy!

I am sure that there are many more commands that re not supported, but this was just a quick test.

Considering PT is supposed to be the platform that engineers start with, it's not teaching you how to be an effective engineer.

There will be occasions when time is not on your side, be it when you are troubleshooting an issue, or when you are taking an exam. You need to learn the little tricks that will make your life as a network engineer easier and more efficient. Packet Tracer will limit you as an engineer. This is why I moved away from it years ago, it certainly won't help you as you progress in your studies. This is why platforms such as UNetLab and GNS3 are so popular. They support the full set of commands, allowing you to become an excellent network engineer, rather than a mediocre one.

When I started writing CCNA and Beyond, I made the decision to aim higher than PT would allow, and you should aim higher as well. Don't be limited by Packet Tracer, aim higher and use a proper platform for your studies.

Packet Tracer will not make you a good engineer, you won't learn the little tricks good engineers use to make their life easier and more effective. Achieving your potential is all about not being limited, Packet Tracer will limit you. You may not see it at the moment, but as you progress, you will start to see this.