Melhores Práticas para Conexões IPsec

Um dos problemas mais comuns ao configurar uma conexão IPsec é a configuração incorreta das configurações IPsec. O elemento chave ao configurar um túnel IPsec é garantir que as configurações correspondam 100% para ambos os pares de conexão. Se as configurações não coincidirem para os dois lados da conexão, problemas de conectividade e roteamento podem ocorrer. Em alguns casos, o túnel pode ser estabelecido, mas se o roteamento não estiver configurado corretamente, o tráfego não poderá ser enviado pelo túnel.

Portanto, recomendamos fortemente que você verifique as configurações IPsec no seu dispositivo de borda (roteador, firewall, VM, etc.) antes de configurar as configurações da conexão IPsec da Cato. Em seguida, use exatamente as mesmas configurações para configurar o site IPsec.

Um dos erros de configuração mais comuns é usar um grupo Diffie-Helman (DH) incompatível. O grupo DH determina o nível de força das chaves usadas para as mensagens de autenticação e inicialização entre os pares de conexão. Se o grupo DH não coincidir em ambos os lados, o túnel falha ao conectar. Portanto, você deve selecionar o grupo DH que coincide em ambos os lados da conexão IPsec. Configure o parâmetro de grupo DH no Aplicativo de Gerenciamento Cato que corresponde à configuração do seu dispositivo de borda.

Outra recomendação importante é para configurações que usam Segredo de Avanço Perfeito (PFS) para renovação de chave. Quando o parâmetro de grupo DH é definido como Nenhum, o PFS está desativado. Portanto, se você está ativando o PFS, verifique se o grupo DH está configurado na seção Parâmetros da Mensagem de Autenticação.

A captura de tela a seguir mostra um exemplo de Parâmetros da Mensagem de Autenticação e opções de grupo DH:

Recomendamos que você evite usar configurações de criptografia fracas, se possível, e utilize um grupo DH mais alto para fornecer um nível de segurança mais alto.

Ao configurar o site no Aplicativo de Gerenciamento Cato, se não houver grupo DH configurado para IKEv2 nos Parâmetros da Mensagem de Autenticação, um grupo DH ainda pode aparecer nos Parâmetros da Mensagem de Inicialização para a Associação de Segurança Infantil (SA). Isso ocorre porque o primeiro SA infantil é sempre criado na troca inicial IKE_AUTH e usa o mesmo material de chave que o IKE SA. O IKE SA usa o grupo DH que está configurado na seção Parâmetros da Mensagem de Inicialização. Não há troca de grupo DH no IKE_AUTH.

Se um grupo DH for configurado na seção Parâmetros da Mensagem de Autenticação, ele será usado apenas durante as trocas CREATE_CHILD_SA, que criam SA infantis adicionais ou renovam as existentes.

Um ponto a ser observado é a incompatibilidade de grupos DH configurados no Aplicativo de Gerenciamento Cato e no par IKEv2. Nessa situação, o túnel é inicialmente estabelecido após a troca IKE_AUTH, mas falha ao renovar usando a troca CREATE_CHILD_SA. Pode haver uma breve interrupção antes que as trocas IKE_SA_INIT e IKE_AUTH restabeleçam o túnel.

É muito importante usar o mesmo algoritmo de criptografia para ambos os pares de conexão. Às vezes, os usuários habilitam vários algoritmos de criptografia em seus dispositivos de borda em vez de escolher um único algoritmo. Habilitar muitos algoritmos leva mais tempo para o dispositivo estabelecer a conexão. Portanto, recomendamos que você habilite apenas o algoritmo que usa em ambos os lados do túnel – menos é melhor.

Para sites IPsec com largura de banda maior que 100Mbps, use apenas os algoritmos AES 128 GCM-16 ou AES 256 GCM-16. Os algoritmos AES CBC são usados apenas em sites com largura de banda menor que 100 Mbps.

Recomendamos que você configure conexões IPsec primárias e secundárias para redundância. Além disso, você deve usar diferentes endereços IP de origem e diferentes PoPs de destino para as conexões. Caso uma origem ou destino falhe ao conectar, e o túnel fique inativo, o segundo túnel passa o tráfego para o outro PoP. Se você configurar o mesmo endereço IP de origem em ambas as conexões primária e secundária e este IP de origem tiver uma falha, nenhuma outra conexão estará disponível para passar o tráfego.

Cato oferece suporte a ambos IKEv1 e IKEv2 para negociação entre os dois pares de conexão. Quando você cria um Site IPsec na Aplicação de Gerenciamento Cato, selecione a versão de Internet Key Exchange suportada (IKEv1 ou IKEv2) que corresponde ao seu dispositivo de borda. Se o IKEv2 for suportado, geralmente recomendamos usá-lo. No entanto, alguns dispositivos não suportam os mesmos parâmetros IKEv2 que estão disponíveis na Aplicação de Gerenciamento Cato. Nesse caso, use o IKEv1. Por exemplo, se o seu firewall não suporta a criptografia AES CBC 256, não a use em sua configuração IPsec. Para mais informações sobre IKEv1 e IKEv2, consulte Cato IPsec Guide: IKEv1 vs IKEv2

Se você tiver um Site IKEv2 ativado, recomendamos fortemente que selecione a opção de Iniciar conexão por Cato. Na maioria dos casos, os dispositivos de borda são configurados com um longo atraso entre as tentativas de reconexão. Quando esses dispositivos iniciam a conexão, o processo de negociação VPN leva muito tempo. Em contraste, quando Cato inicia a conexão, a negociação leva muito menos tempo.

A captura de tela a seguir mostra a opção de iniciador IKEv2:

As configurações de IPsec para diferentes VPNs de fornecedores de nuvem podem ser incompatíveis. Cada fornecedor de nuvem (por exemplo, Amazon AWS, Microsoft Azure ou GCP) usa diferentes configurações de Padrão para túneis IPsec. Verifique a configuração de IPsec do seu fornecedor de nuvem e use uma configuração que corresponda ao Site IPsec da Cato.

Nota: Se você alterar as configurações padrão de IPsec da nuvem, lembre-se de usar as mesmas configurações nas configurações do Site IPsec da Aplicação de Gerenciamento Cato.

Por exemplo, Azure trata o PFS de maneira diferente dependendo se é o iniciador ou respondedor para uma Child SA (ESP SA). Quando é o iniciador, Azure não envia um grupo DH por padrão. Quando é o respondedor, Azure aceita um grupo DH do par. Isso significa que se um grupo DH estiver configurado na seção Parâmetros da Mensagem de Autenticação na Aplicação de Gerenciamento Cato e Azure tentar criar um ESP SA usando a troca CREATE_CHILD_SA, Cato responde com "Nenhuma proposta escolhida" e a SA falha ao se estabelecer. No entanto, se Cato iniciar a troca CREATE_CHILD_SA, o ESP SA se estabelece se o grupo DH configurado for um que Azure aceita como respondedor. Portanto, para garantir compatibilidade máxima com Azure, configure o grupo DH para Nenhum na seção Parâmetros da Mensagem de Autenticação da configuração do Site IKEv2 ou configure uma política personalizada em Azure que especifique o mesmo grupo PFS que o grupo DH configurado na Aplicação de Gerenciamento Cato.

A captura de tela a seguir mostra um exemplo de configuração personalizada de Azure:

Para mais informações sobre parâmetros de VPN de Azure, consulte Sobre Dispositivos de VPN e Parâmetros IPsec.

Cato Networks permite que você selecione parâmetros Automáticos para os Init e Parâmetros da Mensagem de Autenticação do IKEv2, como algoritmos de criptografia, RPF e de integridade. Se você encontrar problemas de conectividade ou roteamento ao usar a configuração automática, recomendamos que você selecione exatamente a configuração que corresponda às configurações do seu dispositivo de borda e evite usar Automático.

No entanto, para sites configurados com GCM para o Algoritmo de Criptografia (AES GCM 128 ou AES GCM 256), então o Algoritmo de Integridade não é relevante porque o GCM também fornece integridade. Quando você seleciona um algoritmo de criptografia AES GCM, o algoritmo de integridade é definido como Automático.