Courseiva
ACLCCNA 200-301

Extended ACL Blocking Return Traffic from Server

Presenting Symptom

Users can initiate connections to the server, but the server's responses are not reaching the clients, causing timeouts or incomplete data transfers.

Network Context

A small enterprise network with a single router (Cisco 4321, IOS 16.9) connecting a client subnet (192.168.1.0/24) and a server subnet (10.0.0.0/24). An extended ACL is applied inbound on the router's interface facing the server to filter traffic to the client subnet. The ACL permits traffic from clients to the server but inadvertently blocks return traffic from the server.

Diagnostic Steps

1

Check ACL configuration on the router

show access-lists
Extended IP access list 100
    10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80
    20 deny ip any any (4 matches)

The ACL shows only a permit statement for traffic from client subnet to server on port 80, and a deny all statement. The matches on the deny line indicate that return traffic is being dropped.

2

Identify which interface the ACL is applied to and direction

show running-config | section interface GigabitEthernet0/0/1
interface GigabitEthernet0/0/1
 ip address 10.0.0.254 255.255.255.0
 ip access-group 100 in

The ACL is applied inbound on the interface facing the server (10.0.0.0/24). This means traffic entering the router from the server is filtered. Since the ACL only permits traffic from clients to server, return traffic from server to clients is denied.

3

Verify connectivity from client to server and server to client

ping 10.0.0.1 source 192.168.1.10
Success rate is 100 percent (5/5)

Ping from client to server succeeds because the ACL permits the ICMP echo request (if permitted) or the ping uses TCP? Actually, the ACL only permits TCP port 80, so ping might be blocked. But if the ACL permits ICMP, it would work. For this scenario, assume the ACL permits only TCP 80, so ping would fail. But the symptom is about TCP return traffic. So we need to test TCP. Use telnet or a tool.

4

Check if the ACL is missing a permit statement for established connections or return traffic

show access-lists 100
Extended IP access list 100
    10 permit tcp 192.168.1.0 0.0.0.255 host 10.0.0.1 eq 80
    20 deny ip any any (10 matches)

The ACL does not have a permit statement for return traffic. For TCP, return traffic has source port 80 and destination port >1023. The ACL should permit traffic from server to client with source port 80. Alternatively, use the 'established' keyword to allow return TCP packets with the ACK bit set.

Root Cause

The extended ACL applied inbound on the router interface facing the server only permits traffic from the client subnet to the server (source client, destination server). It does not permit return traffic from the server to the clients. Since the ACL is applied inbound on the server-facing interface, it filters traffic entering the router from the server. The return packets (server to client) are denied by the implicit deny all or an explicit deny statement.

Resolution

Modify the ACL to permit return traffic from the server to the client subnet. Use the 'established' keyword to allow TCP return packets that have the ACK bit set, or explicitly permit traffic from server port 80 to client high ports. Commands: conf t ip access-list extended 100 permit tcp host 10.0.0.1 eq 80 192.168.1.0 0.0.0.255 established end Alternatively, if the server uses ephemeral ports for return traffic (e.g., for other services), use: permit tcp host 10.0.0.1 eq 80 192.168.1.0 0.0.0.255 established Or more generally: permit tcp host 10.0.0.1 192.168.1.0 0.0.0.255 established

Verification

Run 'show access-lists 100' to see the new entry and verify matches on the deny line stop increasing. Then test connectivity from a client to the server (e.g., HTTP request) and confirm the response is received. Use 'show access-lists 100' again to see matches on the new permit line.

Prevention

1. Always consider return traffic when designing ACLs; use the 'established' keyword for TCP to simplify rules. 2. Apply ACLs as close to the source as possible to reduce complexity. 3. Use named ACLs and document the purpose of each entry.

CCNA Exam Relevance

On the CCNA 200-301 exam, this scenario tests understanding of extended ACLs and the direction of traffic filtering. Questions may present a troubleshooting scenario where a server is unreachable from clients, and candidates must identify that the ACL is blocking return traffic. The exam tests the ability to read ACL configurations and determine the correct permit statements, including the use of the 'established' keyword.

Exam Tips

1.

Remember that ACLs are processed sequentially; the first match applies.

2.

For TCP return traffic, the 'established' keyword matches packets with the ACK or RST bit set.

3.

Know that inbound ACLs filter traffic entering the interface; outbound ACLs filter traffic leaving.

Commands Used in This Scenario

show access-lists

Displays all configured access control lists (ACLs) on the device, including their entries and match counters, used to verify ACL configuration and traffic filtering.

show running-config

Displays the current active configuration in DRAM, showing all non-default settings.

Test Your CCNA Knowledge

Practice with scenario-based questions to prepare for the CCNA 200-301 exam.

Practice CCNA Questions