O aperto de mão TCP falha no Cisco ASA

7

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

cisco-asa firewall tcp

— muehsi
fonte

O que mostra o comando packet-tracer?

— Smithers

O que você quer dizer com comando packet-tracer? Estou trabalhando em um módulo de serviço ASA.

— muehsi

Ah, nunca usei isso. O dispositivo ASA possui um comando "packet-tracer" que simula um pacote executando as regras. Eu acredito que é principalmente para tráfego na camada 3 e acima, mas talvez seja apenas porque eu nunca precisei dele em nenhuma camada inferior. Ponto de interrogação por seu caminho, mas o uso é essencialmente "input pacote-tracer Incoming-ifname tcp SOURCE.IP.ADDRESS.HERE SRC-PORT DST.IP.ADDRESS.HERE DST-PORT"

— Smithers

Sim, isso também está disponível no ASDM. Eu verifiquei isso, e o pacote deve estar passando. Mas não posso escolher pacotes para a configuração da conexão. Só posso verificar o IP e a porta. O problema é que o handshake TCP falha.

— muehsi

Bem, isso SUGERE sua camada 3 é boa, o que é legal. Você desejará capturar TODO o tráfego nas interfaces externas e internas do ASA, incluindo o ARP. Você pode primeiro confirmar se o tráfego está realmente alcançando a interface de entrada e, em seguida, confirmar que não está saindo da saída - porque se está saindo da saída ou não está chegando, provavelmente você tem um problema de comutação.

— Smithers

3

À 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

— Ron Trunk
fonte

Eu adicionei este comando, não sabia que ele existia. Infelizmente, isso não resolveu o meu problema. O Wireshark diz que meu SYN ACK possui um 'ACK = 3200214167', que é estranho, pois foi capturado na interface antes de passar pelo firewall. O Win = 4096 no pacote syn significa alguma coisa para a configuração da conexão?

— muehsi

O Win basicamente significa apenas que há 4kb de espaço disponível no buffer de rede do dispositivo que enviou esse pacote.

— Smithers

11

Percebo que antes do cliente enviar um syn-ack, ele envia um rst-ack. Eu acho que você precisa descobrir isso primeiro.

— Ron Trunk

Não funcionou quando segui esta explicação . Eu também tive que aplicar a política de serviço às interfaces ( service-policy <name> interface <interface>). Obrigado pela sua dica.

— Muehsi 31/07/2015

3

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.

— Eddie
fonte

Obrigado por seus comentários. Eu verifiquei os endereços Ethernet e os corrigi. Como você suspeitava, isso não mudou nada. Eu também inspecionei o problema referente ao RST-ACK e o corrigi. Houve uma configuração incorreta temporária no servidor. No entanto, meu problema de origem ainda ocorre: O SYN-ACKnão passa no firewall. Atualizei os arquivos de captura das interfaces internas / externas para o estado atual.

— Muehsi

Como você 'consertou' o RST-ACK? Esse é o comportamento normal / esperado do servidor. Não olhei para as novas capturas, tentarei quando encontrar mais tempo.

— Eddie

11

@ muehsi, parece-me que você ainda tem um problema. AFAIK, Cloudshark (como o padrão do Wireshark) ajusta os números de sequência exibidos em relação a 0 para facilitar a legibilidade. No entanto, seu SYN-ACK do servidor para o cliente está mostrando que está aceitando 2644561697 em vez de 1. Como o ACK não corresponde ao que o firewall espera ver, ele deve ser descartado.

— YLearn

Em relação ao "comportamento normal" etc. Estamos usando um Spirent TestCenter como gerador de tráfego (para o cliente e o servidor). Portanto, a reação, ou seja, com relação ao comportamento quando nenhum aplicativo está ouvindo uma porta, pode ser diferente de um sistema operacional normal. Mas é por isso que queremos esse handshake de três vias artesanal (apenas como informação de segundo plano).

— precisa

1

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.

— APA
fonte

-1

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.

— Ronnie Royston
fonte

(colega de @muehsi falando) Obrigado pela resposta. No entanto, acho que esse não pode ser o motivo, pois outro tráfego (TCP com estado) que não é feito por pacotes TCP artesanais do gerador de tráfego pode passar o ASA de fora para dentro. De alguma forma, é da natureza dos pacotes que o trafficgen está enviando.

— precisa