Question

Difficulty: Very hardTroubleshooting Routing, Default Gateways, and ACLs

A network administrator is investigating an issue where a workstation configured with IPv4 address 192.168.20.45/24192.168.20.45/24 cannot connect to an internal HTTPS server at 10.50.10.100:44310.50.10.100:443. The network path spans multiple VLANs across a Layer 3 switch, a core router, and perimeter firewalls. Following a systematic network troubleshooting methodology, place the diagnostic steps in the correct logical sequence to systematically isolate whether the root cause lies within the host setup, default gateway reachability, routing table entries, or ACL filtering.

  1. 1Inspect the local IP configuration on the workstation using `ipconfig /all` to confirm the subnet mask and default gateway address (192.168.20.1192.168.20.1).
  2. 2Execute a ping from the workstation to the local gateway interface at 192.168.20.1192.168.20.1 to verify local segment Layer 3 reachability.
  3. 3Run a path trace utility (`tracert 10.50.10.100`) from the workstation to identify the specific hop where packet traversal stops.
  4. 4Log into the router where hop loss occurred and execute `show ip route 10.50.10.100` to verify a valid matching prefix and next-hop path exist.
  5. 5Examine the active Access Control Lists using `show ip access-lists` on the ingress and egress interfaces along the forwarding path to check for explicit or implicit deny rules matching TCP port 443.

Answer

The correct troubleshooting sequence starts by verifying host IP configuration parameters, testing reachability to the local default gateway, tracing the path toward the target server to locate where packets drop, inspecting the routing table at that hop, and finally auditing interface ACLs for filtering rules blocking TCP port 443.
Structured network troubleshooting progresses logically from local host configuration (Layer 1–3) to local gateway connectivity, followed by path discovery (traceroute), transit routing table lookup, and lastly Layer 4 security filtering (ACLs). This bottom-up and path-isolation approach avoids misdiagnosing infrastructure security filters when basic host parameters or gateway routes are misconfigured.

Step-by-Step Solution

1
Verify local IP configuration parameters on the source workstation
Ensures the workstation has a valid IP address, correct subnet mask, and assigned gateway address
Troubleshooting should start closest to the host to eliminate local misconfigurations before investigating network infrastructure.
2
Test connectivity to the default gateway interface
Confirms Layer 2 switch connectivity and Layer 3 local gateway responsiveness
If the workstation cannot reach its gateway, remote routing and ACLs cannot be reached or evaluated.
3
Perform a traceroute to the destination IP address
Identifies the exact transit router hop where packet forwarding ceases
Tracing the path isolates the scope of the problem to a specific router or Layer 3 segment.
4
Examine the IP routing table on the failing router hop
Validates whether an active, valid route exists for the destination subnet
A router without a matching route or valid default route will drop incoming traffic or send an ICMP unreachable message.
5
Inspect interface Access Control Lists (ACLs) along the path
Reveals whether explicit deny rules or the default implicit deny block destination port 443
If routing is operational, packet drops on specific ports (e.g., HTTPS 443) are typically caused by ACL rule ordering or misconfigured filter statements.

Key Concept

CompTIA Layered Network Troubleshooting Methodology for Gateway, Routing, and Access Control List Failures
Estimated Time:2m 0s
Rate this question