Ejemplos de ACL en Packet Tracer: laboratorio estándar y extendido

Planifica la política ACL y la topología antes de escribir

Crea Client-A en 192.168.10.0/24, Client-B en 192.168.20.0/24 y Server-1 en 192.168.30.10/24. Conecta las tres redes al router R1, asigna 192.168.10.1, 192.168.20.1 y 192.168.30.1 a sus interfaces y verifica conectividad completa antes de aplicar filtros. Así puedes separar un error de ACL de un fallo de cableado, interfaz, dirección o ruta.

Escribe la política con lenguaje normal: Client-A puede llegar a la red del servidor, Client-B no puede llegar a Server-1 y el resto del tráfico continúa si el ejercicio no indica lo contrario. Para cada prueba anota origen, destino, protocolo, puerto, interfaz, dirección y resultado esperado.

1. 1

   Construye y direcciona

   Crea las tres redes y activa todas las interfaces.

2. 2

   Comprueba la base

   Haz ping entre redes antes de filtrar.

3. 3

   Define resultados

   Anota qué tráfico debe pasar y cuál debe fallar.

4. 4

   Guarda una copia

   Conserva un PKT anterior a la ACL para comparar.

Compara ACL estándar y ACL extendida

Una ACL IPv4 estándar solo compara la dirección de origen. Resulta adecuada cuando la decisión es permitir o bloquear una red de origen completa. Como no distingue el destino ni el servicio, suele colocarse cerca del destino para no impedir que ese origen llegue a otras redes.

Una ACL extendida puede comparar protocolo, origen, destino y puertos TCP o UDP. Sirve para permitir HTTP y negar ICMP, o para bloquear un cliente concreto frente a un servidor. Normalmente se coloca cerca del origen para descartar pronto el tráfico no deseado.

Ejemplo de ACL estándar: bloquea una red de origen

Para impedir que 192.168.20.0/24 llegue a la LAN del servidor, configura access-list 10 deny 192.168.20.0 0.0.0.255 y después access-list 10 permit any. El permiso explícito es necesario porque la última regla invisible deniega todo lo que no coincidió antes.

Aplica la lista 10 en salida sobre la interfaz que conduce a 192.168.30.0/24 con interface g0/2 e ip access-group 10 out. Esta ubicación bloquea a Client-B solo cuando sale hacia el servidor y mantiene disponibles otros destinos.

1. 1

   Crea la denegación

   Niega 192.168.20.0 con wildcard 0.0.0.255.

2. 2

   Permite los demás orígenes

   Añade permit any antes de la denegación implícita.

3. 3

   Aplica cerca del destino

   Vincula la ACL en salida hacia la red protegida.

4. 4

   Prueba ambos clientes

   Client-B debe fallar y Client-A debe funcionar.

Si ambos clientes fallan, revisa el permiso final, la interfaz y la dirección antes de cambiar direcciones.

Ejemplo de ACL extendida: permite web y niega ping

Para permitir HTTP desde 192.168.10.0/24 a Server-1, usa access-list 110 permit tcp 192.168.10.0 0.0.0.255 host 192.168.30.10 eq 80. Después niega eco ICMP con access-list 110 deny icmp 192.168.10.0 0.0.0.255 host 192.168.30.10 echo. Añade permit ip any any solo si la política escrita permite el resto del tráfico.

Aplica la ACL 110 en entrada sobre la interfaz de R1 conectada a 192.168.10.0/24. Las líneas se evalúan de arriba abajo y la primera coincidencia termina la decisión. Para HTTPS crea una regla específica para el puerto 443 antes de una denegación general.

1. 1

   Permite el servicio

   Coloca primero la regla TCP específica.

2. 2

   Niega el tráfico

   Compara ICMP o el servicio prohibido.

3. 3

   Decide el resto

   Añade permiso final solo si la política lo exige.

4. 4

   Aplica cerca del origen

   Vincula en entrada y repite las pruebas.

Calcula la máscara wildcard y la dirección

Para redes contiguas, resta cada octeto de la máscara a 255. La máscara 255.255.255.0 se convierte en 0.0.0.255 y 255.255.255.192 en 0.0.0.63. Un bit cero debe coincidir y un bit uno puede variar. Usa host 192.168.30.10 para un único equipo y any cuando realmente corresponda a todas las direcciones.

La dirección se interpreta desde el router: entrada es tráfico que entra por la interfaz y salida es tráfico que la abandona. Sigue un paquete desde el origen hasta el destino para elegir el punto correcto.

Verifica tráfico permitido y denegado

Ejecuta al menos una prueba positiva y otra negativa por cada condición. Un ping fallido solo demuestra que algo falló; no demuestra que la ACL correcta haya actuado. Prueba Client-A y Client-B contra Server-1 y también contra un destino no relacionado. Para reglas de servicio, activa HTTP en el servidor y no dependas solo del ping.

Usa show access-lists para revisar orden y contadores, show ip interface para comprobar la ACL aplicada y show running-config para leer la sintaxis. En Simulation mode filtra ARP, ICMP, TCP y HTTP para observar dónde se detiene el paquete.

• Confirma que el tráfico permitido conserva la conectividad base.
• Usa una prueba denegada que coincida exactamente con la regla.
• Revisa contadores después de cada prueba.
• Guarda solo cuando la evidencia coincide con la política.

Soluciona orden, ubicación y denegación implícita

Comprueba primero cableado, estado de interfaces, direcciones, máscaras, puertas de enlace y rutas. Después confirma que la ACL existe, léela de arriba abajo y revisa interfaz y dirección. Busca una regla amplia antes de una específica, una wildcard incorrecta, el puerto en el lado equivocado o un permiso ausente.

Cambia una condición cada vez y repite las mismas pruebas. Si un contador permanece en cero, el tráfico no llega a esa línea o coincide con otra anterior. Si aumenta la línea equivocada, corrige orden o criterios; no acumules comandos aleatorios.