Lab 6

Lab 6: Firewalls Static Packet Filtering
Rich Macfarlane
2.2 Details
Aim: The aim of this lab is to introduce Firewall concepts, using Cisco Static Packet Filters to
apply basic security measures to Network devices. This will lay a foundation for more
complex Firewall architectures.
2.3 Activities
1.2.1 Setup GNS, or Physical Router, Topology
Run the GNS network simulator (as administrator).
Configure GNS3 Preferences, and Images if necessary, as described in previous labs. Configure
the interfaces, and test connectivity. Once the GNS3 topology shown below is created,
configure the router (the configuration in Appendix A can be pasted into the router console as
a shortcut).
Add 2 routers and configure slots to include at least 3 Ethernet interfaces on each router, as
shown below. Add virtual switches to the topology, and cable all network devices together, as
shown below. Labels can also be added by clicking the interface names button, then double
clicking the labels and add the IP Addresses. Add your host machine or VM to the topology, as
described previously.
The Adding VMs to GNS3 guide is available in the following document:
www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf
Starting Topology
Configure the router interfaces as specified in the figure above. The router starting
configurations in Appendix A can be used as a shortcut (cut and paste), or as a guide to
configuring the interfaces. Remember to enable the interfaces with the no shut command.
Network Security Access Control Rich Macfarlane 1

Start the RIP routing protocol on both routers to advertise all the attached sub-networks:
R1(config)# router rip
R1(config-router)# network 0.0.0.0
Run the task manager (and keep it running), and check CPU usage. Recalculate the idlepc
value for the router type, until the CPU usage decreases.
Test connectivity, from each router, to each local router interface, and each of the other
routers interfaces, as shown below.
From R2:
From R1:
etc
Questions
Q: Where the pings from the routers successful?
(If not, troubleshoot the configuration, until connectivity is achieved)
Check Connectivity For All Networks
Check the routing table on each router using the show ip route command. This should

show routes to all connected networks (C), and remote routes advertised by other routers (R).
The R2 routing table should look something like the below.
To test connectivity from the four networks attached to the routers, such as the 192.168.50.0
and 192.168.60.0 networks we can use the extended ping command. The source address can
be entered, thus spoofing where the packets are being sent from. For example, from the R2
router:
R2# ping
Protocol [ip]:
Target IP address: 192.168.2.5
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.50.5
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.5, timeout is 2 seconds:
Packet sent with a source address of 192.168.50.5
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/116/192 ms
R2#
Check connectivity from
192.168.50.5 to 192.168.10.5
192.168.50.5 to 192.168.2.5
192.168.60.5 to 192.168.10.5
192.168.60.5 to 192.168.2.5
Questions
Q: Where the extended pings successful?

YES/NO
(If not, troubleshoot the configuration, until connectivity is achieved)
1.2.2 Basic Static Packet Filtering using Cisco Access Control Lists (ACL)s
Cisco Access Control Lists (ACL) provide static packet filtering on the Cisco network devices. ACLs are
also the basis of creating stateful packet filtering firewalls, both on routers, and on Cisco firewall
hardware appliances (PIX/ASA). Packet filtering is done at Layers 3 and 4 of the TCP/IP network
model as shown below.
OSI Model TCP/IP Model
7. Application
6. Presentation HTTP, FTP , SMTP Application
5. Session
4. Transport TCP, UDP Transport

Packet Filtering
3. Network IP, ICMP Internet
2. Data Link
Ethernet, ATM Network Access
1. Physical
An Access Control List is a packet filtering ruleset, consisting of a list of packet filtering rules, which
are entered into the router Command Line Interface (CLI). Each rule consists of the Access List Id,
which can be a number or name, an Action - Permit or Deny, and the filtering rule itself.
Each rule in the ruleset is compared to the contents of the Layer 3 and Layer 4 packet header
information of each packet in the traffic being filtered.
An implicit deny all rule is automatically added to the end of the ruleset, so the ruleset has a closed
security stance by default. An explicit deny all and log rule can be added so that packets which
dont match any of the rules in the ruleset are logged.
Standard ACLs
Standard ACLs can filter traffic based on source IP address only, so only filter at L3. The
destination IP Address and (Layer 4) TCP information is ignored, so only basic filtering can be
performed.

Command Syntax:
(this is a simplified version of the command syntax, for full command definitions, see Cisco
documentation.
For the ACL:
Router(config)# ip access-list [standard | extended] ACL_NAME
For each rule in a Standard Named ACL gives the same options as the standard numberd:
Router(config-std-nacl)# {permit | deny} {source [source-wildcard] |
any}
Configure a Standard ACL

The following Access Control List (ACL) is designed to block traffic from the 192.168.50.0/24
network at the R2 router. This should stop all other traffic from passing through R2 if the
traffics source is the .50 network.
Router 2
R1(config)# interface fa1/0
R1(config-if)# ip access-group BLOCK_50_NET in
Router 1
fa1/0
Trusted, Internal
Network
R1(config)# ip access-list standard BLOCK_50_NET

R1(config-std-nacl) deny 192.168.50.0 0.0.0.255
R1(config-std-nacl) permit any
The ACL will be applied inbound on the R1 f1/0 interface. Every ACL ruleset has an implicit
deny any as the last rule in the rule set, which causes all traffic that has not matched a rule
in the ACL to be blocked. For this reason, add the permit any statement to the end of the
ACL.
There are 2 steps to an ACL 1. ACL filtering rules are are created, 2. ACL is applied to an
interface, in either an inward or outward direction:
1. Create a Standard Named ACL:
On Router1 create a standard ACL using the following commands:
R1# config t
R1(config)# ip access-list standard BLOCK_50_NET
We enter standard ACL configuration mode (note the router prompt change). Add a rule to
the ACL that uses the deny action to drop any packets from the source the 192.168.50.0/24
network, and logs to the console for each matched packet.
R1(config-std-nacl)# deny 192.168.50.0 0.0.0.255 log

Add a 2nd rule to Permit all other traffic.
R1(config-std-nacl)# permit any
Add a 3rd rule to Explicit deny all other traffic (for good practice only).
R1(config-std-nacl)# deny any
The optional log parameter was used, so if the deny rule matches a packet, as well as
dropping the packet, it should log the packet information and the action taken, locally or to a
logging server.
2. Apply the ACL to an interface:
R1(config)# interface fa1/0

R1(config-if)# ip access-group BLOCK_50_NET in
R1(config-if)# exit
Check the ACL was created, and applied to the interface correctly, by viewing R1s running
configuration.
Questions
Q: Was the ACL created correctly?

YES/NO
Q: Was the ACL applied to the interface correctly? (in the inward direction)
YES/NO
The running-config should contain the following:
Test the ACL

Have the console window for R1 visible for the testing, as the log is being sent to the console
window by default (standard output in Linux terms).

From R2, test the ACL by pinging R1, then using an extended ping from the 192.168.60.5, and
then from 192.168.50.5.
Q: Was the ping from the router successful?

YES/NO
Q: Was the ping from 192.168.50.5 successful?

YES/NO
Q: Did R1 console display any log information? If so what was the message logged?
In the R1 router console you should see the log of the packets being dropped, as shown below:
From Router 2, you should get something similar to the following, where the ping from the R2
router to the 192.168.10.5 is successful, but a ping from the 192.168.50.0 network gets no
response as it is being blocked.

On R1 use the following to show how many packets have matched the ACL rules, and been
dropped:
R1# show access-lists
Standard IP access list BLOCK_50_NET
10 deny 192.168.50.0, wildcard bits 0.0.0.255 log (71 matches)
20 permit any (120 matches)
30 deny any
Q: Why are no packets matched against the deny any rule?
Q: Have we created an open or closed firewall?
Extended ACLs
Extended ACLs filter packets based on (Layer 3) Source and Destination IP Addresses, (Layer
4) Source and Destination TCP and UDP Ports , and Protocol (IP, ICMP, TCP, UDP). The
example below allows all traffic from Bobs subnet to any destination web server, out on the
Internet (TCP Protocol & Port=80).
Command Syntax:
The extended ACL rule command allows more parameters for each rule:
Router(config-ext-nacl)# {permit | deny} protocol source-address
[source-wildcard] [operator operand] destination-address [destination-
wildcard] [operator operand] [established]
Example:
Router(config)# ip access-list extended INBOUND_FROM_INTERNET
Router(config-ext-nacl)# remark Block Invalid Source Addresses From Internet
Router(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any log
Router(config-ext-nacl)# permit ip any 146.1.1.0 0.0.0.255
Router(config-ext-nacl)# deny any any log
Router(config-ext-nacl)# exit
Router(config)#
Router(config)# ip access-list standard INBOUND_FROM_INTERNET

Router(config-ext-nacl)# permit ip any 146.1.1.0 0.0.0.255
Router(config-ext-nacl)# deny any any log
s0
146.1.1.2
Bob
Router(config)# interface s0
Router(config-if)# ip access-group INBOUND_FROM_INTERNET in
146.1.1.1
Figure 1 Named ACL Created and Applied to Boundary Router, to filter inbound traffic
Configure an Extended ACL
The following ACL is to enforce a policy that users on the 192.168.10.5 network are not
allowed access to the Servers on the 192.168.60.5 network. This requires an extended ACL as
source and destination addresses and specific services in the traffic are to be filtered.
1. Create an Extended Named ACL on Router2:
R2# config t
R2(config)# ip access-list extended BLOCK_10_60
We enter standard ACL configuration mode. Add a rule to the ACL that uses the deny action to
drop any packets from the source network of the 192.168.10.0/24 network destined for the
192.168.60.0/24 network, and log to the console for each matched packet.
R2(config-ext-nacl)# deny ip 192.168.10.0 0.0.0.255 192.168.60.0
0.0.0.255 log
Permit all other traffic. Note: the protocol, source and destination networks have to be
specified for the extended ACL rule.
R2(config-ext-nacl)# permit ip any any
Explicit deny all other traffic (Cisco ACLs always have an implicit deny, so it is good practice to
make it explicit for clarity).
R2(config-ext-nacl)# deny ip any any
2. Apply the ACL to an interface:

The ACL is applied to the interface in the inbound direction.
R2(config)# interface f0/0

R2(config-if)# ip access-group BLOCK_10_60 in
R2(config-if)# exit
Check the ACL was created, and applied to the interface correctly, by viewing R2s running
configuration.
Q: Has the ACL been created correctly?
The interfaces and ACL ruleset should be displayed like the following:

Test the ACL
window.
On R2 use the following to check that no packets have matched the ACL rules yet, using the
following command:
R2# show ip access-lists
Extended IP access list BLOCK_10_60
10 deny ip 192.168.10.0 0.0.0.255 192.168.60.0 0.0.0.255 log
20 permit ip any any
30 deny ip any any
R2#
From R1, test the ACL by pinging the 192.168.60.0 network directly from the router. Then
using an extended ping from the 192.168.2.5 to 192.168.60.5, and then from 192.168.10.5 to
192.168.60.5.
Q: Which ping succeeded?

Q: Which ping did not succeed?
Q: Did R2 console display any log information? If so give an outline:
In the R2 router console you should see the log of the packets being dropped, as shown below.
This is just like any firewall log, and can be configured to be written to a central logging server.
You should get something similar to the following, the router to the 192.168.60.0 network is
fine, but the extended ping from the unauthorised 192.168.10.5 network correctly is blocked.
On R2 use the following to show how many packets have matched the ACL rules, and been
dropped or passed by which rules:

Q: Could we have placed this ACL nearer the source network?
Q: On which router / interface?
Q: How many rulesets is it possible to apply to an interface on a Cisco device?
Q: Why would this be difficult to test on Cisco equipment?
1.2.3 Control Access to Remote Administration Services

It is good practice to restrict the access to the virtual interfaces, used for remote
administration using ACLs. Access can be restricted to traffic coming from specific
administration machines, or networks.
System
Administrator
Router(config)# ip access-list standard REMOTE_ACCESS
Router(config-std-nacl)# remark SysAdmin Remote Access
Router(config-std-nacl)# permit host 192.168.2.2
Router(config-std-nacl)# deny any log
192.168.2.2
s0
e0
e4 Eve
192.16810.1 e0
e2
e1 vty 0-4
Bob
192.168.10.2
Router(config)# line vty 0 4

Router(config-line)# access-class REMOTE_ACCESS in
192.168.20.10
Set up Telnet Server on R1

Configure the virtual interfaces access for telnet, with the password telnetpass
R1# config t
Enter configuration commands, one per line. End with CNTL/Z.

R1(config)# line vty 0 4
R1(config-line)# password telnetpass
R1(config-line)# login
R1(config-line)# exit
R1(config)#
From the R2 router, using its using Telnet Client, test the Telnet access to the R1 Telnet server:
Test the telnet access using Putty, from the host (or VM) machine on the 192.168.2.0 network.
Create an ACL to Limit Access to the Telnet Server on R1

Configure a named standard ACL to restrict access to the administrators host machine at
192.168.2.2.
1. Create a Standard Named ACL:

R1# config t
R1(config)# ip access-list standard REMOTE_ACCESS
We enter standard ACL configuration mode. Add a rule to the ACL that uses the permit action
to allow any packets from the source host 192.168.2.2, and logs to the console for each
matched packet.
R1(config-std-nacl)# remark SysAdmin Remote Access
R1(config-std-nacl)# permit 192.168.2.2 0.0.0.0 log
Explicit deny all other traffic to the Telnet server.

R1(config-std-nacl)# deny any log
R1(config-std-nacl)# exit

Q: Why do we log on valid packets?
Q: Why would we want to log invalid Telnet access requests?
Q: Why use the remark command?
Comments and Logging

Notice in the previous example the remark command was used to enter a comment about
the ACL that was being created. This is important, as ACLs can become very large and
complex. The name of the ACL and the remarks can also be seen in the logging information, so
it is important to make them relevant and informative.
2. Apply the ACL to the virtual interfaces:

Apply the ACL to all 5 of the routers virtual terminal interfaces, with commands such as the
following:
R1(config)# line vty 0 4

R1(config-line)# access-class REMOTE_ACCESS in
R1(config-line)# exit
Check the ACL was created, and applied to the interfaces correctly, by viewing R1s running
configuration. See below:
Test the ACL

window (to standard output ).
Test the telnet access using Putty, from the host (or VM) machine on the 192.168.2.0 network.
Q: Was the Telnet connection successful?

Q: Was there anything displayed in the R1 console? Detail:
Test the Telnet access using Telnet Client from R2 router:

Q: Was the Telnet connection successful?
Q: What message was displayed?
Q: Was there anything displayed in the R1 console? Detail:
The Test output should be similar to the following:

From Admin PC:
From R2:
The R1 log msgs should be:
Why do connections from other networks fail, even though they are not listed in the ACL?

1.2.4 Removing ACLs
To delete an ACL from, first remove it from the interface, then remove the ACL itself. When
creating or changing ACLs good practice is to remove the current ACL, delete it and recreate it.
This is much more straightforward then trying to add or edit ACL rules.
Change the BLOCK_10_60 ACL, to also block traffic from the 192.168.2.0 network. First copy
the ACL, from the R2 routers running config. Paste it into a text editor. Then remove the ACL
from the interface on R2.
R2(config-if)# no ip access-group BLOCK_10_60 in
R2(config-if)# exit
Then delete the ACL from the router.

R2# config t
R2(config)# no ip access-list extended BLOCK_10_60
Add a rule to the ACL to block access from the 192.168.2.0 network, and change the name of
the ACL to BLOCK_ALL_60.
Q: What is the new rule?
Create the new rule by pasting the text from the editor into the command line:
R2# config t
R2(config)# ip access-list extended BLOCK_ALL_60
...
Then assign the ACL to the interface:

R2(config-if)# ip access-group BLOCK_ALL_60 in
R2(config-if)# exit
Test with extended pings from all 4 192.168.x.x networks.

Q: Why is it important to keep ACL and Firewall rulesets text files in a safe place?

1.2.5 (Optional Challenge) Add an Linux Server to the Topology
Adding a Virtual Linux Machine to the GNS3 Topology

Start the course Ubuntu virtual machine, in VMWare Workstation. This has several servers
running on it.
The Adding VMs to GNS3 guide is available in the following document:
www.dcs.napier.ac.uk/~cs342/CSN11111/GNSAddVM.pdf
Once you have added the VM:

From GNS3, drag a cloud or Host onto the topology. Then Rightclick->Configure the
computer/cloud to connect to the VMNet1 we have previously set up. Create a manual link
from the VM Linux Servers interface to the routers fa0/0 interface (which should be
configured to be 192.168.10.5), as shown below (create the appropriate labels).
Test connectivity from the router to the new virtual server, as shown below.
Test connectivity from the Linux Server, as shown below.

Test connectivity from the host PC, as shown below.
Test the WebServer

There should be an Apache web server running on the Linux Server. From the host PC or XP VM, use
a web browser to test, as shown below.

Test the Telnet server
From the host PC, or XP VM, login into the Ubuntu VMs Telnet server, using putty. user:
napier (password: napier123).
Test the ftp Server

From your host or XP VM, connect to the FTP Server from, via a web browser using
ftp://w.x.y.z as the URL.
Secure Access using Packet Filtering ACLs

On the R1 Router 192.168.2.5 interface, create on ACL ruleset which only allows VM or host
PC at 192.168.2.2 to access the web server using Web Traffic, or ICMP (ping). The R1 router
should be allowed to ping the Server, but nothing else.
Test that other traffic from 192.168.10.0 network and 10.1.1.0 network cannot get to the
server.
Test that the connectivity pings can.
Test that Web access from 192.168.2.2 is still available.
Test that ftp and Telnet is not available.

2.4 Appendix A Starting router configurations
R1
!
upgrade fpd auto
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R1
!
boot-start-marker
boot-end-marker
!
logging message-counter syslog
!
no aaa new-model
ip source-route
ip cef
!
no ipv6 cef
!
multilink bundle-name authenticated
!
!
archive
log config
hidekeys
!
interface FastEthernet0/0
description to the 192.168.10.0/24 network
ip address 192.168.10.5 255.255.255.0
duplex auto
speed auto
!
description int to the 192.168.2.0/24 network
ip address 192.168.2.5 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.1.1 255.255.255.252
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router rip
network 0.0.0.0
no auto-summary
!
ip forward-protocol nd
no ip http server
no ip http secure-server
!
!
control-plane
!
!
!
mgcp fax t38 ecm
mgcp behavior g729-variants static-pt
!
gatekeeper
shutdown
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
End
R2
!
upgrade fpd auto
version 12.4
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip source-route
ip cef
!
!
no ipv6 cef
!
!
!
!
archive
log config
hidekeys
!
!
!
ip address 10.1.1.2 255.255.255.252
duplex auto
speed auto
!
no ip address
duplex auto
speed auto
!
ip address 192.168.50.5 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.60.5 255.255.255.0
duplex auto
speed auto
!
router rip
network 0.0.0.0
!
no ip http server
!
!
control-plane
!
!
mgcp fax t38 ecm
!
gatekeeper
shutdown
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end
2.5 Appendix B Basic ACLs and Telnet ACL router

configurations
R1
!
upgrade fpd auto

version 12.4
!
hostname R1
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip source-route
ip cef
!
!
no ipv6 cef
!
!
!
archive
log config
hidekeys
!
description to the 192.168.10.0/24 network
ip address 192.168.10.5 255.255.255.0
duplex auto
speed auto
!
description int to the 192.168.2.0/24 network
ip address 192.168.2.5 255.255.255.0
duplex auto
speed auto
!
ip address 10.1.1.1 255.255.255.252
ip access-group BLOCK_50_NET in
duplex auto
speed auto
!
no ip address
shutdown
duplex auto
speed auto
!
router rip
network 0.0.0.0
no auto-summary
!
no ip http server
!
!
!
ip access-list standard BLOCK_50_NET
deny 192.168.50.0 0.0.0.255 log
permit any
deny any
ip access-list standard REMOTE_ACCESS
remark SysAdmin Remote Access

permit 192.168.2.2 log
deny any log
!
ip access-list extended BLOCK_10_WEB_60
deny ip 192.168.10.0 0.0.0.255 192.168.60.0 0.0.0.255 log
permit ip any any
deny ip any any log
!
!
control-plane
!
mgcp fax t38 ecm
!
gatekeeper
shutdown
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
access-class REMOTE_ACCESS in
password telnetpass
login
!
End
R2
!
upgrade fpd auto
version 12.4
!
hostname R2
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
ip source-route
ip cef
!
!
no ipv6 cef
!
!
!
archive
log config
hidekeys
!
!
ip address 10.1.1.2 255.255.255.252
ip access-group BLOCK_10_60 in
duplex auto
speed auto
!
no ip address
duplex auto
speed auto
!
ip address 192.168.50.5 255.255.255.0
duplex auto
speed auto
!
ip address 192.168.60.5 255.255.255.0
duplex auto
speed auto
!
router rip
network 0.0.0.0
!
no ip http server
!
!
ip access-list extended BLOCK_10_60
deny ip 192.168.10.0 0.0.0.255 192.168.60.0 0.0.0.255 log
permit ip any any
deny ip any any
!
!
control-plane
!
mgcp fax t38 ecm
!
!
gatekeeper
shutdown
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end

Lab 6

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Lab 6

Cargado por

Copyright:

Formatos disponibles

Lab 6: Firewalls Static Packet Filtering

Network Security Access Control Rich Macfarlane 1

Q: Where the pings from the routers successful?

(If not, troubleshoot the configuration, until connectivity is achieved)

Check Connectivity For All Networks

Network Security Access Control Rich Macfarlane 2

Check connectivity from

Q: Where the extended pings successful?

OSI Model TCP/IP Model

6. Presentation HTTP, FTP , SMTP Application

4. Transport TCP, UDP Transport

Network Security Access Control Rich Macfarlane 4

Configure a Standard ACL

R1(config)# ip access-list standard BLOCK_50_NET

Network Security Access Control Rich Macfarlane 5

2. Apply the ACL to an interface:

R1(config)# interface fa1/0

Q: Was the ACL created correctly?

The running-config should contain the following:

Test the ACL

Network Security Access Control Rich Macfarlane 6

Q: Was the ping from the router successful?

Q: Was the ping from 192.168.50.5 successful?

Network Security Access Control Rich Macfarlane 7

Q: Why are no packets matched against the deny any rule?

Q: Have we created an open or closed firewall?

Router(config)# ip access-list standard INBOUND_FROM_INTERNET

2. Apply the ACL to an interface:

R2(config)# interface f0/0

Q: Has the ACL been created correctly?

Network Security Access Control Rich Macfarlane 9

Network Security Access Control Rich Macfarlane 10

Q: Did R2 console display any log information? If so give an outline:

Network Security Access Control Rich Macfarlane 11

Q: On which router / interface?

Q: How many rulesets is it possible to apply to an interface on a Cisco device?

Q: Why would this be difficult to test on Cisco equipment?

1.2.3 Control Access to Remote Administration Services

Router(config)# line vty 0 4

Set up Telnet Server on R1

Network Security Access Control Rich Macfarlane 12

Create an ACL to Limit Access to the Telnet Server on R1

1. Create a Standard Named ACL:

Explicit deny all other traffic to the Telnet server.

Network Security Access Control Rich Macfarlane 13

Q: Why would we want to log invalid Telnet access requests?

Q: Why use the remark command?

Comments and Logging

2. Apply the ACL to the virtual interfaces:

R1(config)# line vty 0 4

Test the ACL

Network Security Access Control Rich Macfarlane 14

Test the Telnet access using Telnet Client from R2 router:

Q: What message was displayed?

Q: Was there anything displayed in the R1 console? Detail:

The Test output should be similar to the following:

The R1 log msgs should be:

Network Security Access Control Rich Macfarlane 15

Then delete the ACL from the router.

Q: What is the new rule?

Then assign the ACL to the interface:

Test with extended pings from all 4 192.168.x.x networks.

Network Security Access Control Rich Macfarlane 16