As conexões de mobilidade sem fio falham e não se recuperam quando o ASA é reinicializado

Introduction

Este documento descreve um problema em que uma conexão de caminho de mobilidade (usando o User Datagram Protocol (UDP) e o protocolo IP 93) que atravessa um Adaptive Security Appliance (ASA) pode ficar inoperante e continuar a falhar até que os dispositivos de mobilidade sejam recarregados, ou o tráfego de caminho de mobilidade seja interrompido e deixado inativo por um curto período de tempo e reiniciado.

Prerequisites

Requirements

A Cisco recomenda que você tenha conhecimento destes tópicos:

• Cisco Adaptive Security Appliance (ASA)
• Controlador de LAN sem fio (WLC)

Componentes Utilizados

Este documento não se restringe a versões de software e hardware específicas.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Consulte as Convenções de Dicas Técnicas da Cisco para obter informações sobre convenções de documentos.

Problema

Nessa situação, um Wireless LAN Controller (WLC) em 10.10.1.2 tenta se comunicar com o WLC em 10.10.9.3, mas a comunicação falha.

Esse problema pode ser acionado por qualquer um destes eventos:

• O ASA é reinicializado.
• A tabela de roteamento é modificada por um administrador ou um protocolo de roteamento.
• Uma interface é desativada e, em seguida, ativada novamente pelo administrador.

Além do tráfego de mobilidade, esse problema pode ocorrer para qualquer protocolo IP UDP ou não TCP. 

Esse problema não é um bug, mas uma consequência da topologia de rede e da configuração do ASA. Veja abaixo a causa e a solução para esse problema.

Exemplo de topologia de rede

Configuração de roteamento ASA:

!
route outside 0.0.0.0 0.0.0.0 192.168.4.3 1
route inside 10.0.0.0 255.0.0.0 192.168.254.1 1
!
same-security-traffic permit intra-interface
!

Configuração da interface ASA DMZ:

!
interface Gigabit-Ethernet0/1.10
 vlan 10
 nameif dmz
 security-level 75
 ip address 10.10.9.1 255.255.255.240 standby 10.10.9.2 
!

Disparador de problemas

O problema é acionado quando a WLC em 10.10.1.2 envia tráfego destinado à WLC em 10.10.9.3. Esses pacotes fazem com que o ASA crie uma conexão em sua tabela de conexão que envia o tráfego de mobilidade pela interface ASA errada (interna).

Esse problema é causado pelo fato da interface de destino "dmz" do ASA estar no estado inativo/inativo no momento da criação da conexão, o que resulta na construção da conexão em uma interface diferente, não ideal. A interface dmz pode estar inativa devido a um problema de cabo, a um problema de negociação de ethernet ou canal de porta ou pode estar administrativamente desligada.

No momento do problema, as conexões do caminho de mobilidade podem ser vistas como sendo criadas como "intrainterface" do ASA, que está roteando os pacotes de volta para fora da mesma interface interna em que chegaram:

ASA# show conn address 10.10.1.2
15579 in use, 133142 most used
97 inside 10.10.9.3 inside 10.10.1.2, idle 0:00:00, bytes 32210
UDP inside 10.10.9.3:16666 inside 10.10.1.2:16666, idle 0:00:00, bytes 4338, flags -
97 inside 10.10.9.3 inside 10.10.1.2, idle 0:00:00, bytes 157240
ASA#

O endpoint de mobilidade em 10.10.1.2 continua a enviar tráfego destinado a 10.10.9.3, que corresponde a essas conexões existentes. Mesmo que a interface dmz progredisse para o estado up/up, o tráfego de mobilidade proveniente de 10.10.1.2 corresponderia às conexões existentes na tabela (em vez de criar uma nova conexão com a interface dmz), que redefine o tempo limite das conexões no ASA, o que prolonga o problema.

Em resumo, esses eventos podem disparar o problema:

1. O dispositivo em 10.10.1.2 envia um protocolo 97 ou pacote UDP para 10.10.9.3.
2. O ASA recebe o pacote na interface interna, mas a interface dmz está inativa, o que resulta na rota mais específica para a rede de destino que está faltando na tabela de roteamento. Como o comando same-security permit intrainterface está ativado no ASA, ele segue uma rota estática configurada para a rede 10.0.0.0/8 de volta através da interface interna, cria uma conexão na tabela de conexão e, em seguida, envia o pacote de volta para a interface interna em direção à rede interna.
3. Em algum momento, a interface dmz pode voltar a funcionar e a rota é adicionada novamente à tabela; no entanto, como a conexão para o tráfego do protocolo 97 já foi construída na etapa 2, os pacotes subsequentes corresponderão à conexão e a tabela de roteamento será sobrescrita, e o tráfego não chegará ao servidor na dmz.

Solução

Solução 1

Uma solução possível para esse problema é remover o comando same-security permit intra-interface do ASA. Essa solução impede que a conexão de reversão seja construída de volta na mesma interface na qual o pacote original foi recebido, o que permite que a conexão correta seja construída quando a interface for ativada. No entanto, dependendo da tabela de roteamento do ASA, essa solução pode não funcionar (o tráfego pode ser roteado para outra interface diferente do destino pretendido com base na tabela de roteamento) e o comando same-security permit intrainterface pode ser necessário para outras conexões no ASA.

Solução 2 

Para esta instância específica, o problema foi atenuado com êxito ao ativar o recurso timeout floating-conn. Esse recurso, que não é ativado por padrão, fez com que o ASA desmontasse essas conexões um minuto depois que uma rota mais preferencial para um dos endpoints foi adicionada à tabela de roteamento por meio de uma nova interface do ASA, que ocorre quando a interface dmz é ativada. As conexões são imediatamente recriadas quando o próximo pacote chega ao ASA, usando a interface mais preferencial (dmz, em vez de dentro para o host 10.10.9.3).

ASA(config)# timeout floating-conn 0:01:00

Quando o problema é atenuado, as conexões corretas são criadas na tabela de conexão ASA e a conectividade é automaticamente restaurada:

ASA# show conn address 10.10.1.2
15329 in use, 133142 most used
97 dmz 10.10.9.3 inside10.10.1.2, idle 0:00:00, bytes 3175742510
UDP dmz 10.10.9.3:16666 inside 10.10.1.2:16666, idle 0:00:00, bytes 40651338, flags -
97 dmz 10.10.9.3 inside10.10.1.2, idle 0:00:00, bytes 1593457240
ASA#

Informações Relacionadas

• Referência de comando do ASA 9.1 - comando timeout floating-conn
• Suporte Técnico e Documentação - Cisco Systems