Configuring Standard IP Access Lists

20 Mar

Immediate Solutions
Configuring Standard IP Access Lists

Standard IP access lists provide selection of packets only according to the source IP address contained within the header of the IP packet. To configure a standard IP access list to filter user traffic, use the following steps:

1.Use the following command to define the subnets or host addresses that should either be permitted or denied:

access−list <access−list number> <permit | deny> <source
<source wildcard mask> | any> log

The <access−list number> parameter is the identification number of the access list; the number for a standard IP access list can be any number from 1 to 99. The <source>
identifies the source IP address of the packet. The <source wildcard> is an optional parameter that indicates the wildcard bits that should be applied to the source; if this
parameter is omitted, a mask of 0.0.0.0 is assumed. The parameter any can be used as an abbreviation for the source, which represents 0.0.0.0 255.255.255.255 in dotted decimal notation. The optional log parameter will generate an informational syslog message about a packet that matches the filter rule.

2.Use this command to select the input interface under which the access list will be applied:

interface <interface name> <interface number>

3.Use the following command to apply the access list to the interface:

ip access−group <access−list−number> <in | out>

When the in parameter is defined and the router receives a packet, the router checks the source address of the packet against the access list. If the access list permits the address, the router will continue to process the packet. If the access list rejects the address, the router discards the packet and returns an “ICMP host unreachable” message. When the access list is using the out parameter, after receiving and routing a packet to a controlled interface, the router checks the source address of the packet against the access list. If the access list permits the address, the router forwards the packet out the interface to its final destination. If the access list rejects the address, the router discards the packet and returns an “ICMP host unreachable” message.

Note Any access list defined under an interface without a matching access list entry is interpreted by the router as a permit. This is sometimes called an undefined access list.

Figure 7.4 displays a network with two routers, Router Raul and Router Chris. The routers will be configured to provide packet filtering using standard access lists. Router Raul should be configured to permit only traffic from the 192.168.20.0 network and deny traffic from all other networks. Router Chris will be configured to permit traffic only from 192.168.40.0 and deny traffic from all other networks.

Figure 7.4: Standard access list network.
An inbound access list filter will be applied to the FastEthernet interfaces of each router that permit packets from only the networks mentioned in the preceding paragraph and deny all other packets. The configuration of each router is shown in the following listings: Router Raul’s configuration is shown in Listing 7.1 followed by Router Chris’s configuration in Listing 7.2.

Listing 7.1: Raul’s numbered access list configuration.

hostname Raul
!
interface FastEthernet1/0
ip address 192.168.10.2 255.255.255.0
no ip directed−broadcast
ip access−group 20 in
!
interface FastEthernet2/0
ip address 192.168.40.1 255.255.255.0
no ip directed−broadcast
!
interface FastEthernet3/0
ip address 192.168.50.1 255.255.255.0
no ip directed−broadcast
!
ip route 192.168.20.0 255.255.255.0 192.168.10.1
ip route 192.168.30.0 255.255.255.0 192.168.10.1
!
access−list 20 permit 192.168.20.0 0.0.0.255

Listing 7.2: Chris’s numbered access list configuration.

hostname Chris
!
interface FastEthernet0
ip address 192.168.10.1 255.255.255.0
no ip directed−broadcast
ip access−group 40 in
!
interface Ethernet1
ip address 192.168.20.1 255.255.255.0
no ip directed−broadcast
!
interface FastEthernet1
ip address 192.168.30.1 255.255.255.0
no ip directed−broadcast
!
ip route 192.168.40.0 255.255.255.0 192.168.10.2
ip route 192.168.50.0 255.255.255.0 192.168.10.2
!

access−list 40 permit 192.168.40.0 0.0.0.255

To test the configuration, you can issue the ping IP global command. Raul is configured to accept only inbound packets with a source address within the 192.168.20.0 subnet, and Chris is configured to accept only inbound packets with a source address of 192.168.40.1. From Raul you can issue the ping IP command to test the configuration. First, the configuration will be tested by using an extended ping to verify connectivity to Chris’s FastEthernet1 interface. The packet will be sourced on Raul from its FastEthernet2/0 interface. Because Chris is configured to accept packets from Raul’s 192.168.40.0 network, one would think that configuration would work. To verify this, the debug IP packet command has been issued to display the results of each packet. The output from the ping is shown in Listing 7.3.

Listing 7.3: Issuing the ping command on Raul.

Raul#debug ip packet
ip packet debugging is on
Raul#ping ip
Target ip address: 192.168.30.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.40.1
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 Echo to 192.168.30.1, −
timeout is 2 seconds:
…..
Success rate is 0 percent (0/5)

The output in Listing 7.3 shows that the ping command was not successful. To see why, you can examine the results that are returned by the debug IP packet command. Listing 7.4 displays the results of the command for the ping attempt in Listing 7.3.

Listing 7.4: Results of the debug IP packet command.

ip: s=192.168.40.1, d=192.168.30.1, len 100, sending
ip: s=192.168.30.1, d=192.168.40.1, len 100, access denied
ip: s=192.168.10.2, d=192.168.30.1, len 56, sending.
!
ip: s=192.168.40.1, d=192.168.30.1, len 100, sending
ip: s=192.168.30.1, d=192.168.40.1, len 100, access denied
ip: s=192.168.10.2, d=192.168.30.1, len 56, sending.
!
ip: s=192.168.40.1, d=192.168.30.1, len 100, sending
ip: s=192.168.30.1, d=192.168.40.1, len 100, access denied
ip: s=192.168.10.2, d=192.168.30.1, len 56, sending.

In the first line of the output, the packet is sourced from IP address 192.168.40.1, and its destination is 192.168.30.1; the router tells you that it is sending the packet. The second line of the output displays the problem. The return packet is sourced from 192.168.30.1 and its destination is to IP address 192.168.40.1, but the router denies the packet. If you look back at Raul’s configuration in Listing 7.1. you’ll see that its access list only allows packets from the 192.168.20.0 subnet and not the 192.168.30.0 subnet.

If you were to try the ping command again and time source the packet from the 192.168.40.1 interface with a destination of Chris’s 192.168.20.1 interface, everything should work. Listing 7.5 displays the output of issuing the ping command again on router Raul.

Listing 7.5: Issuing the ping command again on Raul.

Raul#ping ip
Target ip address: 192.168.20.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.40.1
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 Echo to 192.168.20.1, −
timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5)

This time the ping worked. Listing 7.6 displays the results of the debug IP packet command on Raul.

Listing 7.6: Results of the debug IP packet command on Raul.

ip: s=192.168.40.1, d=192.168.20.1, len 100, sending
ip: s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4
!
ip: s=192.168.40.1, d=192.168.20.1, len 100, sending
ip: s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4
!
ip: s=192.168.40.1, d=192.168.20.1, len 100, sending
ip: s=192.168.20.1, d=192.168.40.1, len 100, rcvd 4

Just as expected, the router sourced the ping packet from the 192.168.40.1 interface (which is the IP address that Chris is configured to accept), and the return traffic was sourced from the 192.168.20.1 interface on Chris.

Random Posts

No comments yet

Leave a Reply

You must be logged in to post a comment.