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.

239

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

!

240

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

241

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.

Configuring Extended IP Access Lists

Extended IP access lists match a packet according to the source and destination addresses, and optional protocol type information for finer granularity of control as opposed to standard access lists, which are only matched by the source IP address. This allows for greater flexibility in terms of packet−matching characteristics for deciding whether or not to forward a packet.

242

Except for configuring the packet−matching features of the access list, the process used to configure an extended IP access list is the same process used to configure a standard IP access list. To configure an extended access list, follow these steps:

1. Use the following command to define the extended access list:

access−list <access−list−number> <deny | permit> protocol −

<source source−wildcard> <destination destination−wildcard>− <precedence precedence−value> <tos tos−value> −

<log | log−input>

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 applied inbound or outbound, the access list functions the same as it does in a standard access list configuration (see Step 3 in the section "Configuring Standard IP Access Lists").

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.

In Step 1, the access−list number parameter is the identification number of the access list; the number range for an extended IP access list can be any number from 100 to 199. The protocol specifies either the name or number of an IP protocol that is passed in the header of the packet. The values that can be used for this field are listed in Table 7.2. The source and destination fields specify the number of the network or host in a 32−bit format. The keywords any and host may be used to simplify the configuration. The source−wildcard and the destination−wildcard fields specify the number of wildcard bits that should be applied to the source or destination. The wildcard field can be populated by specifying a 32−bit value, where the value of 1 is not counted. If the keyword any is used for specification of the source or destination, a wildcard mask of all 1s is assumed. If the keyword host is used for specification of the source or destination, a wildcard mask of all 0s is assumed.

Specification of the precedence value is optional and allows for filtering based on the configured precedence value of the packet. The precedence−value field may be populated by either a name or a number. The values that can be used to specify the precedence are listed in Table 7.3.

Table 7.3: Precedence values for extended access lists.

243

Specification of the type−of−service (tos) value configures the router to filter packets based on the type−of−service level configured. The tos−value field may be populated by either a name or number as well, and each of the values may be used in combination. The values that can be used to specify the type−of−service are listed in Table 7.4.

Table 7.4: Type−of−service values for extended access lists.

The optional log parameter will generate an informational syslog message about a packet that matches the filter. Figure 7.5 displays a network in which packet filtering using extended access lists may be used. Raul should be configured to allow only connection requests to 192.168.50.50 from 192.168.30.30 and to allow only connection request from 192.168.20.21 to 192.168.40.41. Listing 7.7 shows the configuration for Raul, and Listing 7.8 shows the configuration for Chris.

244

Figure 7.5: Two routers configured for extended access lists.

Listing 7.7: Extended access list configuration of Raul.

!

interface FastEthernet1/0

ip address 192.168.10.2 255.255.255.0 no ip directed−broadcast

ip access−group 101 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 101 permit ip host 192.168.30.30 host 192.168.50.50 − log

access−list 101 permit ip host 192.168.20.21 host 192.168.40.41 − log

!

Listing 7.8: Extended access list configuration of Chris.

hostname Chris

!

interface FastEthernet0

ip address 192.168.10.1 255.255.255.0 no ip directed−broadcast

!

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

!

The configuration of Raul in Listing 7.7 makes use of the keyword host in the access list

245

configuration. When the host parameter is used, there is no need to specify a wildcard mask because an all 0s mask is assumed by the router. To make sure the configuration is correct and that Raul is allowing only the connections the access list is configured for, you must do some testing. Using the debug IP packet command on Raul will help you to determine the effects of the access list. If you try to ping host 192.168.50.50 from the workstation with the IP address 192.168.30.31, the ping should fail. Listing 7.9 shows an attempt to ping from 192.168.30.31 to 192.168.50.50.

Listing 7.9: Ping attempt to 192.168.50.50 from 192.168.30.31.

C:\>ping 192.168.50.50

Pinging 192.168.50.50 with 32 bytes of data:

Reply from 192.168.10.2: Destination net unreachable

Reply from 192.168.10.2: Destination net unreachable

Reply from 192.168.10.2: Destination net unreachable

Reply from 192.168.10.2: Destination net unreachable

When you look at Raul, which has the debug IP packet command running, you will note that it is denying the ping packet request. In the output in Listing 7.10. you can see the ping packet being denied.

Listing 7.10: Output of the debug IP packet command on Raul.

ip: s=192.168.10.2, d=192.168.30.31, len 56, sending

ip: s=192.168.30.31, d=192.168.50.50, len 100, access denied

!

ip: s=192.168.10.2, d=192.168.30.31, len 56, sending

ip: s=192.168.30.31, d=192.168.50.50, len 100, access denied

!

ip: s=192.168.10.2, d=192.168.30.31, len 56, sending

ip: s=192.168.30.31, d=192.168.50.50, len 100, access denied

!

ip: s=192.168.10.2, d=192.168.30.31, len 56, sending

ip: s=192.168.30.31, d=192.168.50.50, len 100, access denied

The connection request to 192.168.50.50 was denied at Raul because the source of the packet was not configured with a permit statement in the access list. However, if you try to access 192.168.50.50 from 192.168.30.30 using the ping command, everything should work. Listing 7.11 displays the output of the ping command issued on 192.168.30.30.

Listing 7.11: Ping attempt to 192.168.50.50 from 192.168.30.30.

C:\>ping 192.168.50.50

Pinging 192.168.50.50 with 32 bytes of data:

Reply from 192.168.50.50: bytes=32 time=126ms TTL=233

Reply from 192.168.50.50: bytes=32 time=117ms TTL=233

Reply from 192.168.50.50: bytes=32 time=117ms TTL=233

Reply from 192.168.50.50: bytes=32 time=116ms TTL=233

The ping request worked, so now you can look again at the debug output on Raul, as displayed in Listing 7.12.

246