AnyConnect/Cisco Secure Client e IPv6: um problema antigo, um troubleshooting real e um workaround que funciona

Recentemente tratei um problema envolvendo IPv6 e o Cisco Secure Client (CSC) durante conexões de VPN Remote Access em um ambiente com Cisco FTD.

Esse comportamento não foi uma novidade.
Já havia me deparado com esse mesmo cenário outras vezes ao longo do tempo, em ambientes diferentes e com versões distintas de CSC. No entanto, confesso que nunca havia documentado esse problema da forma como ele realmente merece.

Este post nasce exatamente disso:
👉 Um problema real de produção, analisado, reproduzido e mitigado com um workaround, que resolve o sintoma e explica claramente o porquê do comportamento.

O problema observado

Visão geral do problema

O comportamento observado é relativamente simples de identificar:

O endpoint possui conectividade IPv6 funcional
O usuário conecta na VPN Remote Access
Após a conexão:
- IPv6 local para de funcionar
- Apenas tráfego IPv4 segue corretamente
Ao desconectar da VPN, o IPv6 volta a funcionar normalmente

Esse comportamento já foi amplamente discutido em fóruns e está associado a limitações históricas do cliente CSC, especialmente quando IPv6 não é tunelado, mas também não deveria ser quebrado no endpoint.

Em resumo:
Se o IPv6 não é explicitamente tratado na VPN, o cliente acaba interferindo na pilha IPv6 do sistema operacional.

🧠 Por que isso acontece?

Esse comportamento está relacionado ao design do CSC.

Ao estabelecer o túnel VPN, o cliente valida se:

Existe suporte IPv6 configurado no túnel
Existe um IPv6 address pool associado
Existe uma política clara de split tunnel IPv6

Quando essas informações não existem, o cliente assume que:

O IPv6 não está sendo controlado pela VPN
Existe risco de vazamento de tráfego IPv6 fora do túnel

Como medida de proteção, o CSC desabilita o IPv6 nativo do endpoint.

Esse comportamento aparece documentado em diversos fóruns técnicos e está associado a bugs antigos, como o CSCtb74535, que nunca teve correção definitiva.

O objetivo do workaround

O objetivo aqui não é:

Implementar VPN IPv6 real
Tunelar tráfego IPv6 de produção

O objetivo é mais pragmático:
Evitar que o CSC desabilite o IPv6 local do endpoint ao conectar na VPN.

💡 A ideia por trás do workaround

O workaround se baseia em fornecer ao cliente VPN os elementos mínimos para que ele entenda que:

O túnel VPN possui suporte IPv6
Existe uma política definida para IPv6

Para isso:

Cria-se um IPv6 pool fictício
Associa-se esse pool ao Remote Access VPN
Configura-se IPv6 Split Tunnel Policy = Tunnel specified
Informa-se apenas esse IPv6 fictício na lista

Com isso:

O CSC considera o IPv6 “controlado”
O IPv6 real não é tunelado
O IPv6 nativo do endpoint permanece ativo

Passo a passo do workaround para o FTD

Criar um IPv6 Pool fictício no FMC

Para que o CSC entenda que o túnel VPN possui suporte a IPv6, o primeiro passo consiste na criação de um IPv6 Pool fictício no Firepower Management Center (FMC).

Esse pool não será usado para tráfego IPv6 real, mas faz parte do workaround necessário para evitar que o IPv6 nativo do endpoint seja desabilitado ao conectar na VPN.

No FMC, navegue até:

Objects / Object Management / Address Pools / IPv6 Pools

FMC – Navegação IPv6 Pool

Após acessar o menu IPv6 Pools no FMC, clique em Add IPv6 Pools para criar o pool IPv6 que será utilizado como parte do workaround.

Configuração IPv6 Pool

A imagem acima mostra a tela de criação de um IPv6 Pool no FMC. Esse pool será utilizado exclusivamente para satisfazer a validação de suporte IPv6 do CSC durante a conexão VPN, não sendo usado para tráfego IPv6 real.

Parâmetros configurados

Na criação do pool, foi utilizado os seguintes valores:

Explicação dos campos

Name: Identifica claramente que se trata de um pool IPv6 fictício utilizado como workaround para o Remote Access VPN.
IPv6 Address: prefixo pertencente ao bloco 2001:db8::/32, reservado para documentação.
O endereço ::1/64 é aceito pelo FMC como ponto inicial do pool.
Number of Addresses: define a quantidade de endereços disponíveis dentro do prefixo.
Para este cenário, o valor 100 é mais do que suficiente, já que os endereços não serão utilizados de forma efetiva.

Criação do Objeto de Rede IPv6 para Split Tunneling

Antes da configuração da ACL de Split Tunnel IPv6, é necessário criar o objeto de rede que representará o prefixo IPv6 a ser tunelado pelo Remote Access VPN.
Esse objeto será posteriormente referenciado diretamente na ACL de Split Tunnel, definindo quais redes IPv6 devem trafegar através do túnel VPN.

Caminho no FMC:

Objects / Object Management / Network

Configuração do Network Object:

Name: RA_VPN_SPLIT_TUNNEL_IPV6
Type: Network
IPv6 Network: 2001:db8:10:10::/64

Este objeto representa explicitamente a rede IPv6 autorizada para tunelamento e será utilizado nos próximos passos, durante a criação da ACL de Split Tunneling IPv6.

IPv6 Network Object

Referência à ACL de Split Tunneling Existente (IPv4)

Caminho no FMC:

Objects / Object Management / Access List / Extended

A imagem abaixo referencia uma ACL de Split Tunneling já existente no ambiente, utilizada atualmente para o tunelamento das redes IPv4, especificamente a rede 172.16.0.0/12.

Neste momento, não há criação de uma nova ACL.
O objetivo deste passo é editar a ACL existente, que já está associada ao perfil de VPN Remote Access, para incluir também o tráfego IPv6 no Split Tunnel.

ACL IPv4 existente

Inclusão do IPv6 na ACL de Split Tunneling

Após a criação do objeto de rede IPv6, o próximo passo é editar a ACL de Split Tunneling existente e incluir explicitamente a rede IPv6 que deverá ser tunelada.

ACL IPv6 adicionada

Nesta imagem, a ACL já se encontra editada com a nova entrada permitindo o tráfego IPv6. Clique em Save.

ACL Configurada

Acesso à política de VPN Remote Access no FMC

A imagem abaixo ilustra o caminho de navegação no FMC para acessar a configuração da VPN Remote Access, onde será realizada a associação do IPv6 Pool criado anteriormente.

Neste passo, deve-se acessar o menu:
Devices / VPN / Remote Access

Na configuração do ambiente de LAB será editada a Connection Profile LAB-VPN-CCIE, e nela vamos adicionar o pool IPv6 VPN_IPV6_FAKE_POOL.

Connection Profile LAB-VPN-CCIE

O que está sendo configurado neste passo?

Dentro do Connection Profile, na seção Client Address Assignment, é possível definir quais pools de endereçamento serão utilizados para os clientes VPN.

Neste cenário:

O pool IPv4 já se encontra configurado e operacional
É adicionada uma nova entrada do tipo IPv6, selecionando o IPv6 Pool criado anteriormente
O objetivo não é fornecer conectividade IPv6 real pelo túnel, mas sim evitar que o CSC desabilite o IPv6 local do usuário

Connection Profile – Associação do Pool

Nesta etapa, foi realizada a associação dos pools de endereços IP ao Connection Profile da VPN de Acesso Remoto.
O perfil LAB-VPN-CCIE foi vinculado à Group Policy correspondente, permitindo a atribuição dinâmica de endereços aos usuários remotos.

A configuração possibilita a seleção de pools IPv4 e IPv6, garantindo compatibilidade com ambientes dual-stack e atendendo aos critérios definidos para a política de endereçamento dos clientes VPN.

Connection Profile – IPv6 Pool

Aqui realizamos a configuração da Group Policy, responsável por definir os parâmetros aplicados aos usuários da VPN.
O Split Tunneling IPv6 foi configurado para permitir apenas as redes especificadas na Extended ACL, garantindo controle preciso do tráfego que deve passar pelo túnel VPN.
Após a validação das opções, a política foi salva e vinculada ao Connection Profile.

Group Policy

O que esse workaround faz na prática?

Com Tunnel specified:

Somente os prefixos IPv6 listados entram no túnel
Todo o restante do tráfego IPv6 sai localmente

Como o prefixo listado é fictício:

Nenhum IPv6 real passa pela VPN
O CSC mantém o IPv6 local ativo

Resultado obtido

Após aplicar esse workaround:

✔ VPN IPv4 continuou funcionando
✔ IPv6 local do endpoint permaneceu ativo
✔ Não foi necessário ajuste no endpoint
✔ O impacto para o usuário final foi eliminado

Limitações do workaround

É importante deixar claro:

Esse workaround não resolve a causa raiz
Não cria VPN IPv6 funcional
Não transporta tráfego IPv6 real
Existe para mitigar um comportamento conhecido do cliente

Conclusão

Esse é um típico caso onde o problema não está na rede local, nem no IPv6 do endpoint, mas sim no comportamento do cliente VPN diante da ausência de configuração IPv6 no túnel.

Documentar esse tipo de workaround ajuda a: