Perguntas frequentes sobre IPsec: Por que os telefones Avaya não podem mais se conectar via IPsec VPN após a atualização do código no ASA?

Introduction

Este documento descreve um problema encontrado quando a Avaya é implantada em um sistema no qual os telefones usam o cliente IPsec (Internet Protocol Security) integrado.

Por que os telefones Avaya não podem mais se conectar via IPSEC VPN após a atualização de código no Cisco Adaptive Security Appliance (ASA)?

Para entender esse problema, você precisa entender como a NAT-T (Network Address Translation Traversal, tradução de endereço de rede) e a NAT Discovery (NAT-D) funcionam. O processo NAT-D compreende estas etapas:

1. Detecta um ou mais dispositivos NAT entre hosts IPsec.
2. Identifica se o peer suporta NAT-T.
3. Negocia o uso do encapsulamento UDP (User Datagram Protocol) de pacotes IPsec através de dispositivos NAT no Internet Key Exchange (IKE).

O NAT-D envia os hashes dos endereços IP e das portas de ambos os pares IKE de cada extremidade para a outra. Se ambas as extremidades calcularem esses hashes e produzirem os mesmos resultados, elas saberão que não há NAT entre elas. Os hashes são enviados como uma série de payloads NAT-D. Cada payload contém um hash. No caso de vários hashes, vários payloads NAT-D são enviados. Normalmente, há apenas dois payloads NAT-D. Os payloads NAT-D estão incluídos no terceiro e quarto pacotes do modo principal e no segundo e terceiro pacotes do modo agressivo. Como este exemplo usa um túnel de acesso remoto, ele é o Modo agressivo.

Um dos detalhes incluídos nos payloads NAT-D é o VID (Vendor ID, ID do fornecedor). A troca de VIDs entre pares ajuda a determinar o recurso NAT-T do host remoto, conforme descrito em Request for Comments (RFC) 3947:

The format of the NAT-D packet is:

        1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
      +---------------+---------------+---------------+---------------+
      | Next Payload  | RESERVED      | Payload length                |
      +---------------+---------------+---------------+---------------+
      ~                 HASH of the address and port
      +---------------+---------------+---------------+---------------+

   The payload type for the NAT discovery payload is 20.

O tipo de payload aceito atual do payload NAT-D é 20. Se você observar as depurações no ASA, verá:

[IKEv1]IP = 192.168.96.120, IKE_DECODE RECEIVED Message (msgid=0) with payloads:
HDR + KE (4) + NONCE (10) + UNKNOWN (15), *** ERROR *** + UNKNOWN (15),
*** ERROR *** + NONE (0) total length : 232

Aqui estão os instantâneos das capturas de pacotes:

ASA para telefone:

Telefone para ASA:

A Avaya não reconhece o payload 20 e o ASA não entende o tipo de payload 15. A explicação para esse comportamento é que, em 2004, o mesmo RFC definiu o tipo de payload como 15. Portanto, desde 2004, os telefones Avaya que usam esse tipo de payload não são mais compatíveis com RFC. Então, por que funcionou com um código mais antigo? Porque, como a Avaya, alguns dos códigos mais antigos (versão 8.0.x) ainda suportam a ID antiga. No entanto, o código mais recente (versões 8.2.1+) deve ser compatível com o novo valor de RFC e não deve suportar o tipo de payload15. No entanto, você pode encontrar várias versões que ainda suportam o tipo de payload15, que é o que causa o problema.

A Avaya precisa corrigir o firmware no telefone para que o cliente VPN integrado use a ID de payload correta. Infelizmente, alguns outros telefones Avaya, como o 46xx Series, não estão mais em produção e não terão uma correção. Nesse caso, é necessário obter um novo equipamento ou fazer o downgrade do ASA para uma versão em que ele estava funcionando. Obviamente, esta última opção não está disponível se você fez o upgrade para obter uma correção de bug. Qualquer versão do software da Cisco que funcione com a ID de payload mais antiga precisa ser relatada e o problema corrigido nessas versões.