HP Procurve 5406zl - Problema de ACL


7

Tengo un problema con una ACL en una interfaz VLAN. He seguido la documentación de HP aquí: http://h20628.www2.hp.com/km-ext/kmcsdirect/emr_na-c02609963-3.pdf

Quiero hacer lo siguiente:

La VLAN 101 solo debe poder comunicarse con la VLAN 50, sin otras VLAN, sin acceso a Internet.

Inicialmente, probé la siguiente lista de acceso:

ip access-list extended "SecureContent"
    10 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255
    20 remark "SecurityVLAN"

Apliqué esta ACL a la VLAN 101 "en" con el siguiente comando:

  vlan 101
    ip access-group "SecureContent" in

Esta configuración da como resultado una comunicación cero en esa VLAN: la IP de 192.168.101.2 en el puerto A1 no puede hacer ping a 192.168.101.1, la IP VLAN del conmutador. Si cambio la lista de acceso a:

10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255 
20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255

... esto da como resultado que los clientes en la VLAN puedan hacer ping a su puerta de enlace predeterminada, pero no a la puerta de enlace 50.1. Eso no tiene ningún sentido para mí: la interfaz IP de la VLAN 101 debe considerarse lógicamente "dentro" de esa VLAN 101, ¿correcto?

He intentado varias versiones de esta lista de acceso, incluso yendo tan lejos como para hacer solo una lista de acceso estándar que bloquea una sola IP pero permite todo lo demás con una declaración "permit ip any any", y esto todavía resulta en cero inter o intra- tráfico vlan: el host en esa VLAN ni siquiera puede hacer ping a su propia puerta de enlace si aplico la lista en la dirección de entrada (también probé una variante en la dirección de salida: ¡exactamente el mismo resultado!)

A continuación se muestra la configuración del interruptor:

    Running configuration:

; J8697A Configuration Editor; Created on release #K.15.09.0012
; Ver #03:01.1f.ef:f2
hostname "HP-5406zl"
module 1 type j8702a
module 2 type j8708a
module 3 type j9546a
module 4 type j8708a
power-over-ethernet pre-std-detect
ip access-list extended "SecureContent"
     10 permit ip 192.168.101.1 0.0.0.255 192.168.101.1 0.0.0.255
     20 permit ip 192.168.50.1 0.0.0.255 192.168.101.1 0.0.0.255
   exit
ip route 0.0.0.0 0.0.0.0 172.16.0.1
ip routing
snmp-server community "public" unrestricted
snmp-server contact "Person" location "Place"
vlan 1
   name "DEFAULT_VLAN"
   no untagged A1-A20,A23-A24,B1-B4,C1-C8,D1-D4
   untagged A21-A22
   ip address 192.168.1.10 255.255.255.0
   jumbo
   exit
vlan 50
   name "Editors"
   untagged A2-A19,B1-B3,C1-C8,D1-D4
   tagged A23-A24
   ip address 192.168.50.1 255.255.255.0
   jumbo
   exit
vlan 100
   name "IO"
   tagged A23-A24
   ip address 192.168.100.1 255.255.255.0
   exit
vlan 101
   name "SecureContent"
   untagged A1
   ip address 192.168.101.1 255.255.255.0
   ip access-group “SecureContent” in
   exit
vlan 200
   name "Corp"
   tagged A23-A24
   ip address 192.168.200.1 255.255.255.0
   ip helper-address 192.168.50.2
   exit
vlan 800
   name "IT"
   untagged A23-A24
   ip address 172.17.0.1 255.255.255.0
   exit
vlan 899
   name "DMZ"
   untagged B4
   tagged A23-A24
   ip address 172.18.0.1 255.255.255.0
   jumbo
   exit
vlan 900
   name "Routed"
   untagged A20
   tagged A23-A24
   ip address 172.16.0.2 255.255.255.252
   exit
vlan 999
   name "VLAN999"
   no ip address
   exit

EDITADO para agregar información relevante del chasis:

  Software revision  : K.15.09.0012         Base MAC Addr      : 002561-f80000
  ROM Version        : K.15.30              Serial Number      : XXXXXXXX
  Allow V1 Modules   : Yes     

         Opacity Shields    : Not Installed

¡Gracias de antemano por tu ayuda!


Estoy tratando de bloquear el ping icmp entre vlans específicos, cuando aplico la misma configuración en cisco funciona, pero cuando lo intento en la serie hp5400 no funciona. Digamos: Vlan-10 (192.168.10.1/24) Vlan-20 (192.168.20.1/24) La configuración de muestra sería la siguiente ... # ip access-list extended "130" 10 deny icmp 192.168.10.0 255.255.255.0 192.168.20.0 255.255.255.0 20 permiso ip 0.0.0.0 255.255.255.255 0.0.0.0 255.255.255.255 Vlan 10 ip acceso-grupo 130 en ¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡¡
khan

Respuestas:


7

De acuerdo con la Guía de seguridad de acceso para su dispositivo, la primera dirección y máscara de un ACE es la fuente y la segunda dirección y máscara es el destino. (Por si acaso, un ACE es una entrada de control de acceso; es decir, cualquier línea de la que esté hecha una lista de acceso)

ACE 20 de su ACL indica la fuente 192.168.50.0/24 y el destino 192.168.101.0/24, luego aplica la ACL en la entrada VLAN 101; sin embargo, su VLAN 101 es 192.168.101.0/24, por lo que cualquier tráfico de entrada en VLAN 101 tendría la dirección de origen en 192.168.101.0/24. Entonces, ACE 20 en su ACL está mal, necesita un ACE con permiso de acción, fuente 192.168.101.0/24 y destino 192.168.50.0/24.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255

Con respecto al camino de regreso para este tráfico, cruzará la VLAN 101 de salida, por lo que ACL no debe aplicarse a este tráfico y debe permitirse.

Si el tráfico de regreso no está permitido, entonces debe agregar el camino de regreso en su ACL.

ip access-list extended "SecureContent"
    10 permit ip 192.168.101.0 0.0.0.255 192.168.50.0 0.0.0.255
    20 permit ip 192.168.50.0 0.0.0.255 192.168.101.0 0.0.0.255

EDITADO para cambiar la línea de arriba para reflejar la estructura ACL adecuada de las entradas numeradas. (10, 20, etc.)


Interesante: los dispositivos HP manejan esa lógica ACL de manera totalmente diferente de las cosas de Cisco. Gracias por tus ideas. ¡Intentaré esto!
Panther Modern

1
¿Cuáles son las diferencias que estás encontrando? Mi experiencia es principalmente con equipo de Cisco y no encuentro esta configuración muy diferente ...
Daniel Yuste Aroca

Todas mis ACL en el equipo de Cisco funcionan sin las entradas para el tráfico de retorno.
Panther Modern

Para aclarar: nunca he tenido que construir ACL de tráfico de retorno en el equipo de Cisco, excepto en los firewalls Pix más antiguos. Todas las ACL de switch parecen funcionar bien con las entradas individuales que uso.
Panther Modern

1
Gracias por la confirmación Panther Modern, he editado la respuesta nuevamente para que sea correcta según su experiencia
Daniel Yuste Aroca

2

Parece que este problema se debe a la forma en que el equipo de red de HP maneja las ACL versus Cisco (que es mi experiencia en redes).

Según este documento, las ACL de HP no tienen estado y deben contener entradas de tráfico bidireccionales (para tráfico de origen y tráfico de retorno): http://tinyurl.com/qbfemk6 (Enlace a PDF en el sitio de HP).

Esto contrasta con la guía de Administración avanzada de tráfico anterior, que muestra ejemplos de configuración que no implementan o explican esta "peculiaridad": los ejemplos no contienen tales entradas de tráfico de retorno.

Lecciones aprendidas: No confíe en que la documentación del fabricante sea coherente y precisa.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.