TCP Handshake falla en Cisco ASA

7

Estoy usando un generador de tráfico para configurar una conexión TCP que debería pasar un firewall Cisco ASA.

Mi topología se ve así: 

                     +------------------+                      
                     |  CISCO ASA       |                      
+------------+       |                  |                      
|  Client    +-------+Outside           |                      
|  10.1.202.1|       |10.1.202.254      |                      
|            |       |                  |        +------------+
+------------+       |            Inside|        |Server      |
                     |      10.1.102.254+--------+10.1.102.19 |
                     |                  |        |            |
                     +------------------+        +------------+

La conexión debe establecerse desde un host en la red externa (10.1.202.1/24) a un servidor en la red interna (10.1.102.19/24).

Veo en Wireshark que la SYNpasa el servidor de seguridad (. 10,1 (1/2) 02,254), el SYN-ACK no pasa y se deja caer (ver capturas: en el interior de la interfaz y el exterior de la interfaz ).

Según show asp dropme informan, los marcos se descartan debido a la siguiente razón:

TCP failed 3 way handshake (tcp-3whs-failed)

No estoy usando ARP, pero uso la dirección MAC de la interfaz del firewall, que es la puerta de enlace predeterminada.

Creo el SYN, SYN-ACKy me ACKgusta lo siguiente:

SYN: (Cliente (fuera) al servidor (dentro)

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 0
Acknowledgement number: 0
Synchronize: 1
Acknowledgement: 0

SYN-ACK: (Servidor (dentro) al cliente (fuera)) (esto no pasa el firewall)

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.102.19
Destination IP: 10.1.202.1
Default Gateway: 10.1.102.254

**TCP**
Source Port: 8000
Destination Port: 9000
Sequence number: 0
Acknowledgement number: 1
Synchronize: 1
Acknowledgement: 1

ACK: (Cliente (externo) al servidor (interno))

**Ethernet**
Destination MAC: <Mac Address of the Firewall-Interface>
Source MAC: <Mac Address of the Sending Device-Interface>

**IP**
Source IP: 10.1.202.1
Destination IP: 10.1.102.19
Default Gateway: 10.1.202.254

**TCP**
Source Port: 9000
Destination Port: 8000
Sequence number: 1
Acknowledgement number: 1
Synchronize: 0
Acknowledgement: 1

Además, mi topología es la siguiente:

El cliente generador de tráfico (fuera de la red) está conectado a un conmutador en el que se agrega una VLAN. El conmutador está conectado a la interfaz de firewall externa. En la red interna, el generador de tráfico está conectado al conmutador donde se agregan etiquetas VLAN y el conmutador está conectado a la interfaz interna del firewall.

¿Alguien puede decirme por qué el ASA deja caer el SYN-ACK?

¡Gracias por adelantado!

EDITAR:

  • Como sugirió Ron Trunk, deshabilité la aleatorización de los números de secuencia usando:

    número de secuencia aleatoria deshabilitado

  • Añadido captura del interior de la interfaz y el exterior de la interfaz .

  • Actualizado los archivos de captura

cisco-asa firewall tcp muehsi
fuente
¿Qué muestra el comando packet-tracer?
Smithers
¿Qué quieres decir con el comando del paquete de seguimiento? Estoy trabajando en un módulo de servicio ASA.
muehsi
Ah, nunca usé eso. El dispositivo ASA tiene un comando "paquete-trazador" que simula un paquete que se ejecuta a través de las reglas. Creo que es principalmente para el tráfico en la capa 3 y superior, pero tal vez eso es solo porque nunca lo necesité en ninguna capa inferior. El signo de interrogación se abre paso a través de él, pero el uso es esencialmente "entrada de trazador de paquetes INCOMING-IFNAME tcp SOURCE.IP.ADDRESS.HERE SRC-PORT DST.IP.ADDRESS.HERE DST-PORT"
Smithers
Sí, esto también está disponible en ASDM. Lo comprobé y el paquete debería pasar. Pero no puedo elegir paquetes para la configuración de la conexión. Solo puedo verificar la IP y el puerto. El problema es que el protocolo de enlace TCP falla.
muehsi
Bueno, eso SUGIERE que tu capa 3 sea buena, lo cual es bueno Querrá capturar TODO el tráfico en las interfaces externas e internas del ASA, incluido ARP. Primero puede confirmar si el tráfico realmente está llegando a la interfaz de ingreso, y luego confirmar que no está saliendo de la salida, porque si ESTÁ saliendo de su salida o NO llega a su ingreso, probablemente tenga un problema de cambio.
Smithers

Respuestas:

3

Por defecto, el ASA aleatoriza los números de secuencia en el protocolo de enlace (para evitar secuestros de sesión). Entonces sus números de secuencia no coinciden. Puedes desactivar esa función.

random-sequence-number disable
Ron Trunk
fuente
Agregué este comando, no sabía que existía. Lamentablemente no resolvió mi problema. Wireshark dice que mi SYN ACK tiene un 'ACK = 3200214167' que es extraño ya que fue capturado en la interfaz antes de pasar el firewall. ¿Win = 4096 en el paquete de sincronización significa algo para la configuración de la conexión?
muehsi
El Win esencialmente solo significa que hay 4kb de espacio disponible en el búfer de red del dispositivo que envió ese paquete.
Smithers
1
Noto que antes de que el cliente envíe un syn-ack, envía un primer ack. Creo que primero debes resolver eso.
Ron Trunk
No funcionó cuando seguí esta explicación . También tuve que aplicar la política de servicio a las interfaces ( service-policy <name> interface <interface>). Gracias por tu pista.
muehsi
3

En su captura interna , hay dos paquetes que van del Servidor (10.1.102.19) al Cliente (10.1.202.1), pero provienen de diferentes direcciones MAC.

#23 Ethernet II, Src: 00:10:94:00:00:01 (00:10:94:00:00:01), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 19112639, Len: 0

#25 Ethernet II, Src: 00:10:94:00:00:02 (00:10:94:00:00:02), Dst: 00:19:55:07:12:ca (00:19:55:07:12:ca)
    Internet Protocol Version 4, Src: 10.1.102.19 (10.1.102.19), Dst: 10.1.202.1 (10.1.202.1)
    Transmission Control Protocol, Src Port: 8000 (8000), Dst Port: 9000 (9000), Seq: 0, Ack: 1, Len: 0

Eso parece extraño, pero probablemente no sea tu problema. Hasta donde puedo interpretarlo, su problema es el siguiente:

Parece que el servidor en sí responde naturalmente a su paquete SYN diseñado con el RST-ACK en el paquete # 23 (de la tapa interna, ver arriba), probablemente porque el puerto 8000 está cerrado. Esto hará que el cortafuegos reenvíe el RST al exterior (paquete n. ° 23 en la tapa exterior) y purgue esta conexión de su tabla de estado.

Pero su paquete SYN-ACK diseñado se dispara en el n. ° 25 (de la tapa interior), lo que provoca un RST del cortafuegos (n. ° 26) porque no hay una entrada en la tabla de conexión relacionada con este flujo.

Eddie
fuente
Gracias por tus comentarios. Verifiqué las direcciones de Ethernet y las arreglé. Como sospechabas, esto no cambió nada. También he inspeccionado el problema relacionado con el RST-ACK y lo solucioné. Ha habido una mala configuración temporal en el servidor. Sin embargo, mi problema de origen aún ocurre: SYN-ACKno pasa el firewall. He actualizado los archivos de captura de las interfaces internas / externas al estado actual.
muehsi
¿Cómo 'arreglaste' el RST-ACK? Ese es el comportamiento normal / esperado del servidor. No he mirado las nuevas capturas, lo intentaré cuando encuentre más tiempo.
Eddie
1
@muehsi, me parece que todavía tienes un problema. AFAIK, Cloudshark (como el valor predeterminado de Wireshark) ajusta los números de secuencia mostrados en relación con 0 para facilitar la lectura. Sin embargo, su SYN-ACK del servidor al cliente muestra que está ACKing 2644561697 en lugar de 1. Como el ACK no coincide con lo que el firewall espera ver, debería soltarlo.
YLearn
Con respecto al "comportamiento normal", etc. Estamos utilizando un Spirent TestCenter como generador de tráfico (tanto para el cliente como para el servidor). Entonces, la reacción, es decir, con respecto al comportamiento cuando ninguna aplicación está escuchando un puerto, podría ser diferente a un sistema operativo normal. Pero es por eso que queremos este apretón de manos de 3 vías hecho a mano (solo como información de fondo).
StephenKing
1

¿Puede ejecutar lo siguiente en su ASA?

// Habilita todas las capturas para todas las gotas de asp

ASA# capture asp-drop type asp-drop all

// Muestra el búfer de captura que debe identificar por qué falla el apretón de manos

ASA# sh capture asp-drop

Debería mostrar algo similar a lo siguiente pero para su tipo específico de caída:

   2 packets captured
   1: 15:15:00.682154 197.2.1.29.2616 > 87.200.42.101.443: S 1239395083:1239395083(0) win 65535 <mss 1260,nop,nop,sackOK> Drop-reason: (acl-drop) Flow is denied by configured rule
   4: 15:15:00.750830 10.70.0.162.3812 > 168.252.3.41.15: S 3523756300:3523756300(0) win 65535 <mss 1360,nop,nop,sackOK> Drop-reason: (rpf-violated) Reverse-path verify failed

Tenga en cuenta que una regla básica para el ASA es que para iniciar el tráfico desde una interfaz de menor seguridad (Exterior) a una interfaz de mayor seguridad (Interior) debe haber una entrada de ACL explícita para permitir el paso de este tráfico. Sin ver su configuración ASA, es difícil saber qué podría estar causando los problemas.

APA
fuente
-1

Está describiendo el funcionamiento normal / predeterminado del ASA. Solo se permiten conexiones TCP establecidas de EXTERIOR a INTERIOR. Puede deshabilitar esto configurando TCP State Bypass .

Step 1 Choose Configuration > Firewall > Service Policy.

Step 2 Click Add > Add Service Policy Rule.

Alternatively, if you already have a rule for the hosts, edit the rule.

Step 3 Select whether to apply the rule to a specific interface or globally to all interfaces, and click Next.

Step 4 For Traffic Classification, select Source and Destination IP Addresses (uses ACL) and click Next.

Step 5 For the ACL rule, enter the IP addresses of the hosts on each end of the route in Source and Destination, and specify the protocol as TCP. Click Next when finished.

For example, if you want to bypass TCP state checking between 10.1.1.1 and 10.2.2.2, enter:

Source = 10.1.1.1
Destination = 10.2.2.2
Destination Protocol = tcp
Step 6 On the Rule Actions page, click the Connection Settings tab and select TCP State Bypass.

Step 7 Click Finish to save the rule, and Apply to update the device.
Ronnie Royston
fuente
(colega de @muehsi hablando) Gracias por su respuesta. Sin embargo, creo que esta no puede ser la razón, ya que otro tráfico (TCP con estado) que no está hecho por paquetes TCP hechos a mano desde el generador de tráfico puede pasar el ASA de afuera hacia adentro. De alguna manera está en la naturaleza de los paquetes que el trafficgen está enviando.
StephenKing