Network Security Access Control Rich Macfarlane 1

Lab 6: Firewalls Static Packet Filtering

Rich Macfarlane, Oct 2013
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 2



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
Network Security Access Control Rich Macfarlane 3



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
Network Security Access Control Rich Macfarlane 4



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.


Application
Transport
Internet
Network Access
OSI Model TCP/IP Model
Ethernet, ATM
IP, ICMP
HTTP, FTP , SMTP
TCP, UDP
7. Application
6. Presentation
5. Session
4. Transport
3. Network
2. Data Link
1. Physical
Packet Filtering


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.
Network Security Access Control Rich Macfarlane 5



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.
fa1/0
R1(config)# interface fa1/0
R1(config-if)# ip access-group BLOCK_50_NET in
Trusted, Internal
Network
Router 1
Router 2
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

Network Security Access Control Rich Macfarlane 6



Add a 2
nd
rule to Permit all other traffic.
R1(config-std-nacl)# permit any

Add a 3
rd
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).

Network Security Access Control Rich Macfarlane 7



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.


Network Security Access Control Rich Macfarlane 8



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)# deny ip 0.0.0.0 0.255.255.255 any log
Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.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)# deny ip 127.0.0.0 0.255.255.255 any log
Router(config-ext-nacl)# deny ip 0.0.0.0 0.255.255.255 any log
Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.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
Bob
Router(config)# interface s0
Router(config-if)# ip access-group INBOUND_FROM_INTERNET in
s0
146.1.1.1
146.1.1.2

Figure 1 Named ACL Created and Applied to Boundary Router, to filter inbound traffic
Network Security Access Control Rich Macfarlane 9



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:
Network Security Access Control Rich Macfarlane 10





Test the ACL
Have the console window for R2 visible for the testing, as the log is being sent to the console
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?


Network Security Access Control Rich Macfarlane 11



Q: Which ping did not succeed?


Q: Did R1 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 R1 use the following to show how many packets have matched the ACL rules, and been
dropped or passed by which rules:
Network Security Access Control Rich Macfarlane 12






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?


Q: Why would this be difficult to test?




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.

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
Bob
s0
192.168.10.2
192.16810.1
e0
192.168.20.10
e0
e1
e2
System
Administrator
192.168.2.2
Router(config)# line vty 0 4
Router(config-line)# access-class REMOTE_ACCESS in
e4
Eve
vty 0-4


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.
Network Security Access Control Rich Macfarlane 13



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

Network Security Access Control Rich Macfarlane 14



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
Have the console window for R1 visible for the testing, as the log is being sent to the console
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?

Network Security Access Control Rich Macfarlane 15



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?



Network Security Access Control Rich Macfarlane 16




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)# interface f0/0
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.2 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)# interface f0/0
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?




Network Security Access Control Rich Macfarlane 17



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 just 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.
Network Security Access Control Rich Macfarlane 18





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.




Network Security Access Control Rich Macfarlane 19



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.


Network Security Access Control Rich Macfarlane 20



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
!
interface FastEthernet0/1
description int to the 192.168.2.0/24 network
ip address 192.168.2.5 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.1.1.1 255.255.255.252
duplex auto
speed auto
!
interface FastEthernet1/1
no ip address
shutdown
duplex auto
speed auto
Network Security Access Control Rich Macfarlane 21



!
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
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
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
ip address 10.1.1.2 255.255.255.252
duplex auto
speed auto
Network Security Access Control Rich Macfarlane 22



!
interface FastEthernet0/1
no ip address
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.50.5 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 192.168.60.5 255.255.255.0
duplex auto
speed auto
!
router rip
network 0.0.0.0
!
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
2.5 Appendix B Basic ACLs and Telnet ACL router
configurations


R1
!
upgrade fpd auto
Network Security Access Control Rich Macfarlane 23



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
!
interface FastEthernet0/1
description int to the 192.168.2.0/24 network
ip address 192.168.2.5 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 10.1.1.1 255.255.255.252
ip access-group BLOCK_50_NET in
duplex auto
speed auto
!
interface FastEthernet1/1
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
!
!
!
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
Network Security Access Control Rich Macfarlane 24



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
mgcp behavior g729-variants static-pt
!
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
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname R2
!
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
ip address 10.1.1.2 255.255.255.252
ip access-group BLOCK_10_60 in
duplex auto
speed auto
!
interface FastEthernet0/1
Network Security Access Control Rich Macfarlane 25



no ip address
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 192.168.50.5 255.255.255.0
duplex auto
speed auto
!
interface FastEthernet1/1
ip address 192.168.60.5 255.255.255.0
duplex auto
speed auto
!
router rip
network 0.0.0.0
!
ip forward-protocol nd
no ip http server
no ip http secure-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
mgcp behavior g729-variants static-pt
!
!
gatekeeper
shutdown
!
!
line con 0
stopbits 1
line aux 0
stopbits 1
line vty 0 4
login
!
end