O aperto de mão TCP falha no Cisco ASA

Estou usando um gerador de tráfego para configurar uma conexão TCP que deve passar por um firewall do Cisco ASA.

Minha topologia fica assim:

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

A conexão deve ser estabelecida de um host na rede externa (10.1.202.1/24) para um servidor na rede interna (10.1.102.19/24).

Eu vejo em Wireshark que a SYNpassa o firewall (. 10,1 (1/2) 02,254), o SYN-ACK não passar e cair (ver capturas: dentro da interface e o fora-de interface ).

De show asp dropsou informado de que os quadros são descartados devido ao seguinte motivo:

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

Não estou usando o ARP, mas uso o endereço MAC da interface do firewall, que é o gateway padrão.

Eu crio o SYN, SYN-ACKe ACKcomo o seguinte:

SYN: (cliente (externo) para 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: 0
Acknowledgement number: 0
Synchronize: 1
Acknowledgement: 0

SYN-ACK: (servidor (interno) para cliente (externo)) (isso não passa o 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) para 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

Além disso, minha topologia é como a seguir:

O cliente gerador de tráfego (rede externa) está conectado a um switch no qual uma VLAN é adicionada. O switch está conectado à interface externa do firewall. Na rede interna, o gerador de tráfego é conectado ao switch em que as tags VLAN são adicionadas e o switch é conectado à interface interna do firewall.

Alguém pode me dizer por que o ASA deixa cair o SYN-ACK?

Desde já, obrigado!

EDITAR:

• Conforme sugerido por Ron Trunk, desabilitei a randomização dos números de sequência usando:

  desativação de número de sequência aleatória

• Adicionado captura da interface interna e externa .

• Atualizado os arquivos de captura

À revelia, o ASA randomiza os números de sequência no aperto de mão (para impedir seqüestros de sessão). Portanto, seus números de sequência não coincidem. Você pode desativar esse recurso.

random-sequence-number disable

Na sua captura interna , existem dois pacotes que vão do Servidor (10.1.102.19) para o Cliente (10.1.202.1), mas eles são provenientes de diferentes endereços 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

Isso parece estranho, mas provavelmente não é seu problema. Tanto quanto eu posso interpretar, seu problema é o seguinte:

Parece que o próprio servidor responde naturalmente ao seu pacote SYN criado com o RST-ACK no pacote nº 23 (da tampa interna, veja acima) - provavelmente porque a porta 8000 está fechada. Isso solicitará que o Firewall encaminhe o RST para o exterior (pacote nº 23 na tampa externa) e limpe essa conexão de sua tabela de estados.

Mas o pacote SYN-ACK criado é acionado no 25 (da tampa interna), solicitando um RST do Firewall (26) porque não há entrada na tabela de conexão relacionada a esse fluxo.

Você pode executar o seguinte em seu ASA, por favor:

// Ativar todas as capturas para todos os asp asp

ASA# capture asp-drop type asp-drop all

// Mostra o buffer de captura que deve identificar por que o handshake está falhando

ASA# sh capture asp-drop

Deve mostrar algo semelhante ao seguinte, mas para o seu tipo específico de queda:

   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

Lembre-se de que uma regra básica para o ASA é que, para iniciar o tráfego de uma interface de segurança mais baixa (Fora) para uma interface de segurança mais alta (Dentro), deve haver uma entrada explícita da ACL para permitir a passagem desse tráfego. Sem ver sua configuração ASA, é difícil dizer o que pode estar causando os problemas.

Você está descrevendo a operação normal / padrão do ASA. Somente conexões TCP estabelecidas são permitidas de FORA para DENTRO. Você pode desativar isso configurando o desvio de estado TCP .

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.