Aula 16: VPN com IPsec — site-to-site e remote access no Cisco IOS

Bem-vindo à Aula 16 do curso Cisco IOS — Do Zero ao Avançado. Nesta etapa decisiva da sua jornada, você vai dominar um dos pilares da conectividade segura moderna: a VPN com IPsec. Seja para interligar filiais de forma transparente ou para permitir que colaboradores acessem recursos corporativos de qualquer lugar do mundo, o IPsec continua sendo o padrão ouro em segurança de camada 3 — e o Cisco IOS oferece um arsenal completo para implementá-lo com precisão cirúrgica. Ao final desta aula, você será capaz de projetar, configurar e diagnosticar túneis VPN site-to-site e soluções de acesso remoto usando exclusivamente a CLI do IOS, sem depender de assistentes gráficos ou ferramentas externas.

Por que esta aula é tão crítica? Em nossos projetos na JRT Technology Solutions, encontramos diariamente cenários onde a comunicação entre datacenters, escritórios e usuários móveis precisa ser protegida contra interceptação, adulteração e spoofing. O IPsec resolve esses três problemas simultaneamente: confidencialidade via criptografia simétrica, integridade via hashing e autenticação via chaves pré-compartilhadas ou certificados digitais. Contudo, a complexidade do protocolo — com suas fases IKEv1/IKEv2, transform sets, mapas criptográficos e políticas de isakmp — costuma ser uma barreira significativa mesmo para profissionais experientes. Esta aula vai derrubar esses muros com explicações didáticas e exercícios práticos que você executará passo a passo.

Os pré-requisitos já foram cobertos nas aulas anteriores: você deve ter pleno domínio de endereçamento IP, roteamento estático e dinâmico (Aulas 9 a 13), listas de acesso (Aula 14) e conceitos fundamentais de criptografia simétrica/assimétrica e hashing (Aula 15). Seu laboratório deve contar com pelo menos dois roteadores Cisco com imagem IOS que suporte o feature set securityk9 ou superior — condição indispensável para os comandos crypto. Utilizaremos o Cisco IOS 15.6(3)M7 como referência, mas as configurações são retrocompatíveis com versões 12.4(15)T e posteriores. Lembre-se de que as interfaces devem estar funcionalmente ativas e com conectividade IP básica entre os peers antes de começarmos a configuração criptográfica.

Ao concluir esta aula, você terá implementado com sucesso: um túnel VPN com IPsec site-to-site completo entre dois roteadores, com tráfego protegido por ESP, autenticação HMAC-SHA256 e criptografia AES-256; uma solução de VPN com IPsec para acesso remoto utilizando o Cisco VPN Client (legado) ou o AnyConnect com IKEv2, autenticando usuários contra uma base local AAA; verificações de estado de túnel com comandos show e debug; e o diagnóstico de pelo menos quatro cenários de falha comuns. Vamos construir conhecimento sólido e imediatamente aplicável.

O que você vai aprender nesta aula

• Compreender a arquitetura do IPsec: protocolos AH/ESP, modos túnel e transporte, e as duas fases do IKE
• Configurar uma VPN com IPsec site-to-site completa entre dois roteadores Cisco, incluindo ISAKMP, transform sets, crypto maps e ACLs de tráfego interessante
• Implementar uma VPN com IPsec remote access com autenticação local e pool de endereços, utilizando o recurso crypto dynamic-map
• Verificar o estado dos túneis com comandos show crypto isakmp sa, show crypto ipsec sa e ferramentas de debug controlado
• Diagnosticar e corrigir erros comuns de configuração, como mismatch de pre-shared key, transform set incompatível e problemas de roteamento reverso
• Aplicar boas práticas de hardening e otimização de túneis aprendidas em campo pela equipe da JRT Technology Solutions

Pré-requisitos e ambiente de laboratório

Para executar todos os procedimentos desta aula sem interrupções, você precisará de um ambiente mínimo composto por:

1. Dois roteadores Cisco (físicos ou virtualizados via GNS3/EVE-NG) com IOS versão 15.x — recomendamos as imagens c2900-universalk9-mz.SPA.156-3.M7.bin ou equivalentes. Ambos devem possuir o pacote de segurança (securityk9) habilitado, verificável com o comando show license ou show version.
2. Conectividade IP entre os roteadores — para a VPN site-to-site, as interfaces WAN (ex: GigabitEthernet0/0 em cada lado) devem se comunicar via ping. Nesta aula usaremos a rede 10.0.0.0/30 entre os peers.
3. Redes locais simuladas — no site A (R1) usaremos a LAN 192.168.1.0/24 e no site B (R2) a LAN 172.16.1.0/24, representando os segmentos que serão interligados pelo túnel.
4. Para o remote access, um roteador atuando como servidor VPN e um cliente (pode ser outro roteador configurado como crypto client ou o Cisco VPN Client em uma máquina virtual Windows/Linux). Nesta aula configuraremos um terceiro roteador (R3) como cliente.
5. Console ou acesso SSH a todos os dispositivos — jamais configure túneis IPsec remotamente sem um canal alternativo de acesso; uma interrupção na WAN durante a configuração pode deixá-lo sem gerenciar o roteador.

Nossos especialistas da JRT Technology Solutions utilizam diariamente o EVE-NG Community Edition para simular este exato cenário antes de qualquer implementação em produção — é uma prática que recomendamos fortemente.

Arquitetura do IPsec: o que acontece dentro do túnel

Antes de mergulharmos nos comandos, é essencial compreender a arquitetura do IPsec, porque a maioria dos erros de configuração deriva de uma compreensão superficial de suas fases. O IPsec não é um protocolo único, mas um framework composto por vários subprotocolos que negociam, estabelecem e mantém associações de segurança (Security Associations — SAs). Cada SA é um canal unidirecional que define como o tráfego será protegido entre dois pontos. Como o tráfego de rede geralmente flui em ambas as direções, uma comunicação IPsec típica requer pelo menos duas SAs: uma de ida e outra de volta.

A primeira etapa é o IKE (Internet Key Exchange), que atua como um protocolo de controle para negociar os parâmetros de segurança antes que os dados reais possam fluir. O IKE opera em duas fases distintas e complementares. A Fase 1 estabelece um canal seguro e autenticado entre os dispositivos — imagine-a como a construção de um túnel blindado dentro do qual todas as negociações subsequentes ocorrerão. Esta fase resulta na ISAKMP SA (ou IKE SA). Nela, os peers negociam: algoritmo de criptografia (DES, 3DES, AES-128/192/256), algoritmo de hash (MD5, SHA-1, SHA-256), método de autenticação (pre-shared key, certificados RSA, EAP) e grupo Diffie-Hellman (1, 2, 5, 14, 19, 20, 21).

A Fase 2 utiliza o canal seguro estabelecido na Fase 1 para negociar os parâmetros específicos que protegerão o tráfego de dados propriamente dito. É aqui que se definem o protocolo ESP (Encapsulating Security Payload) — e ocasionalmente o AH —, o modo de operação (túnel, o mais comum, ou transporte), os algoritmos de criptografia e hash para os dados, e os proxy identities, que são os seletores de tráfego (quais redes de origem e destino serão protegidas). A Fase 2 cria as IPsec SAs, que possuem uma vida útil configurável (default de 1 hora ou 4.608.000 kilobytes, o que ocorrer primeiro) e são renovadas automaticamente. Quando ambas as fases são concluídas com sucesso, o túnel VPN com IPsec está pronto para o tráfego de produção.

Um detalhe que frequentemente escapa aos iniciantes: o IKEv1 possui dois modos de Fase 1 — Main Mode (seis pacotes trocados, preserva o anonimato das identidades) e Aggressive Mode (três pacotes, mais rápido mas expõe hashes das chaves). O Cisco IOS utiliza Main Mode por padrão quando configuramos pre-shared keys com IP fixo. Já o IKEv2 simplifica essa estrutura, combinando as duas fases em uma troca única de quatro mensagens (IKE_SA_INIT e IKE_AUTH), sendo mais robusto contra ataques DoS e suportando nativamente EAP para autenticação de usuários remotos. Nesta aula trabalharemos com ambos os cenários: IKEv1 para a VPN site-to-site e IKEv2 para remote access.

Configurando VPN com IPsec site-to-site — cenário e topologia

Agora que os fundamentos estão claros, vamos à implementação prática. Nossa topologia para a VPN com IPsec site-to-site consiste em dois roteadores conectados por suas interfaces WAN. O R1 representa a Matriz (site A), com interface GigabitEthernet0/0 no IP 10.0.0.1/30 e interface GigabitEthernet0/1 atendendo a LAN 192.168.1.0/24 (gateway .1). O R2 representa a Filial (site B), com GigabitEthernet0/0 no IP 10.0.0.2/30 e GigabitEthernet0/1 na LAN 172.16.1.0/24 (gateway .1). O tráfego entre as LANs deverá ser criptografado e transportado através do túnel IPsec, enquanto o tráfego entre as WANs (10.0.0.x) permanecerá em claro — essa é a definição clássica de crypto ACL.

Antes de qualquer comando relacionado a IPsec, é fundamental estabelecer conectividade IP entre os peers. Execute as configurações básicas de interface, roteamento (uma rota estática para a WAN do peer é suficiente para este laboratório) e verifique com ping. Um erro comum é pular esta etapa e gastar horas depurando ISAKMP quando o problema é simplesmente a falta de rota. Em nossos projetos na JRT Technology Solutions, sempre iniciamos com um checklist de camadas 1 a 3 antes de adicionar a camada de segurança.

Configuração base — R1 (Matriz)

! Configuração inicial do R1
enable
configure terminal

! Interface WAN conectada ao R2
interface GigabitEthernet0/0
 description WAN para R2 - VPN peer
 ip address 10.0.0.1 255.255.255.252
 no shutdown

! Interface LAN local
interface GigabitEthernet0/1
 description LAN Matriz - 192.168.1.0/24
 ip address 192.168.1.1 255.255.255.0
 no shutdown

! Rota para a LAN remota via WAN (será sobreposta pelo túnel IPsec depois)
ip route 172.16.1.0 255.255.255.0 10.0.0.2

! Salvar configuração
do write memory

Configuração base — R2 (Filial)

! Configuração inicial do R2
enable
configure terminal

! Interface WAN conectada ao R1
interface GigabitEthernet0/0
 description WAN para R1 - VPN peer
 ip address 10.0.0.2 255.255.255.252
 no shutdown

! Interface LAN local
interface GigabitEthernet0/1
 description LAN Filial - 172.16.1.0/24
 ip address 172.16.1.1 255.255.255.0
 no shutdown

! Rota para a LAN remota via WAN
ip route 192.168.1.0 255.255.255.0 10.0.0.1

! Salvar configuração
do write memory

VPN com IPsec site-to-site — configuração criptográfica completa no R1

A configuração de VPN com IPsec em Cisco IOS segue uma sequência lógica que deve ser respeitada para que as políticas se associem corretamente. Inicialmente, definimos os parâmetros da Fase 1 (ISAKMP Policy), depois a chave pré-compartilhada, em seguida os parâmetros da Fase 2 (Transform Set), então a ACL de tráfego interessante e finalmente o Crypto Map, que amarra todos esses elementos e é aplicado à interface WAN. Vamos configurar o R1 passo a passo, com comentários em linha explicando cada decisão.

! ============================================================
! CONFIGURAÇÃO DE VPN IPSEC SITE-TO-SITE — R1 (MATRIZ)
! ============================================================

enable
configure terminal

! --- PASSO 1: Política ISAKMP (Fase 1) ---
! Definimos uma política com prioridade 10 (quanto menor, mais preferencial).
! Os parâmetros escolhidos seguem recomendações de hardening atuais:
! AES-256 (criptografia forte), SHA-256 (hash resistente a colisões),
! grupo Diffie-Hellman 14 (2048 bits, bom equilíbrio segurança/performance),
! e tempo de vida de 86400 segundos (24 horas).
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
 exit

! --- PASSO 2: Chave pré-compartilhada ---
! Vinculamos a chave ao endereço IP do peer remoto (R2).
! A senha "JRT@VPN_Secret2026!" deve ser idêntica em ambos os lados.
! Em produção, utilize senhas com mínimo 16 caracteres, incluindo maiúsculas,
! minúsculas, números e caracteres especiais.
crypto isakmp key JRT@VPN_Secret2026! address 10.0.0.2

! --- PASSO 3: Transform Set (Fase 2) ---
! Define como o tráfego de dados será protegido.
! Usaremos ESP (não AH), com criptografia AES-256 e HMAC-SHA256 para integridade.
! O modo tunnel é o padrão e protege o pacote IP original inteiro.
crypto ipsec transform-set TS-SITE-TO-SITE esp-aes 256 esp-sha256-hmac
 mode tunnel
 exit

! --- PASSO 4: ACL de tráfego interessante ---
! Especifica qual tráfego deve ser protegido pelo túnel IPsec.
! Origem: LAN Matriz | Destino: LAN Filial.
! Tráfego que NÃO bate nesta ACL NÃO será criptografado.
access-list 101 permit ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255

! --- PASSO 5: Crypto Map ---
! Amarra todos os elementos anteriores e é aplicado na interface WAN.
! O número 10 é a sequência, útil quando há múltiplos peers no mesmo map.
crypto map CMAP-SITE-TO-SITE 10 ipsec-isakmp
 description VPN para Filial (R2)
 set peer 10.0.0.2
 set transform-set TS-SITE-TO-SITE
 match address 101
 exit

! --- PASSO 6: Aplicar Crypto Map na interface WAN ---
interface GigabitEthernet0/0
 crypto map CMAP-SITE-TO-SITE
 no shutdown
 exit

! --- PASSO 7: Garantir que o tráfego do túnel não seja NATeado (se NAT estiver ativo) ---
! No nosso cenário não configuramos NAT, mas em produção é essencial.
! access-list 102 deny ip 192.168.1.0 0.0.0.255 172.16.1.0 0.0.0.255
! access-list 102 permit ip 192.168.1.0 0.0.0.255 any
! route-map RM-NO-NAT permit 10
!  match ip address 102
! ip nat inside source route-map RM-NO-NAT interface GigabitEthernet0/0 overload

! Salvar
do write memory

VPN com IPsec site-to-site — configuração criptográfica completa no R2

A configuração do R2 é essencialmente simétrica, invertendo os endereços de origem/destino na ACL e o IP do peer no comando set peer. A consistência entre as políticas ISAKMP e os transform sets é absolutamente crítica — um simples mismatch de algoritmo de hash ou grupo Diffie-Hellman resultará em falha silenciosa na negociação. Observe os comandos completos:

! ============================================================
! CONFIGURAÇÃO DE VPN IPSEC SITE-TO-SITE — R2 (FILIAL)
! ============================================================

enable
configure terminal

! --- PASSO 1: Política ISAKMP (Fase 1) ---
! Deve ser IDÊNTICA à do R1 em todos os parâmetros.
crypto isakmp policy 10
 encryption aes 256
 hash sha256
 authentication pre-share
 group 14
 lifetime 86400
 exit

! --- PASSO 2: Chave pré-compartilhada ---
! Apontando para o IP do peer R1 (10.0.0.1).
crypto isakmp key JRT@VPN_Secret2026! address 10.0.0.1

! --- PASSO 3: Transform Set (Fase 2) ---
! O nome pode ser diferente, mas os parâmetros DEVEM CASAR.
! Se no R1 usamos esp-aes 256 e esp-sha256-hmac, aqui repetimos exatamente.
crypto ipsec transform-set TS-SITE-TO-SITE esp-aes 256 esp-sha256-hmac
 mode tunnel
 exit

! --- PASSO 4: ACL de tráfego interessante ---
! Agora origem = LAN Filial, destino = LAN Matriz.
! A simetria é obrigatória: se o R1 usa origem 192.168.1.0, aqui DEVE ser destino.
access-list 101 permit ip 172.16.1.0 0.0.0.255 192.168.1.0 0.0.0.255

! --- PASSO 5: Crypto Map ---
crypto map CMAP-SITE-TO-SITE 10 ipsec-isakmp
 description VPN para Matriz (R1)
 set peer 10.0.0.1
 set transform-set TS-SITE-TO-SITE
 match address 101
 exit

! --- PASSO 6: Aplicar na interface WAN ---
interface GigabitEthernet0/0
 crypto map CMAP-SITE-TO-SITE
 no shutdown
 exit

! Salvar
do write memory

Verificando a instalação e testando a configuração site-to-site

Agora que ambos os lados estão configurados, precisamos ativar o túnel e verificar seu funcionamento. No Cisco IOS, a negociação ISAKMP não inicia automaticamente pela simples aplicação do crypto map — é necessário gerar tráfego interessante que bata nas ACLs para disparar a Fase 1. Esse é um comportamento que confunde muitos iniciantes. Vamos gerar esse tráfego com um ping originado na LAN do R1 com destino à LAN do R2, e em seguida executar os comandos de verificação que revelarão o estado do túnel.

! ============================================================
! GERAÇÃO DE TRÁFEGO INTERESSANTE E VERIFICAÇÃO
! ============================================================

! No R1: ping da LAN Matriz para a LAN Filial, com source na interface LAN
ping 172.16.1.1 source GigabitEthernet0/1 repeat 5

! Imediatamente após, verificar as SAs de ISAKMP (Fase 1)
show crypto isakmp sa

! Verificar as SAs de IPsec (Fase 2) com detalhes completos
show crypto ipsec sa

! Verificar o resumo do crypto map e quais peers estão definidos
show crypto map

A saída esperada no R1 para o comando show crypto isakmp sa deve mostrar uma única sessão no estado QM_IDLE, indicando que a Fase 1 foi concluída e a Fase 2 está negociada:

IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
10.0.0.2        10.0.0.1        QM_IDLE           1001    0 ACTIVE

Para o comando show crypto ipsec sa, a saída será bastante detalhada. Procure especificamente pela seção da interface GigabitEthernet0/0 e verifique se os contadores pkts encaps e pkts decaps estão aumentando, e se o campo current_peer mostra o IP correto. Eis um recorte do que você deve observar em um túnel saudável:

interface: GigabitEthernet0/0
    Crypto map tag: CMAP-SITE-TO-SITE, local addr 10.0.0.1

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
   remote ident (addr/mask/prot/port): (172.16.1.0/255.255.255.0/0/0)
   current_peer 10.0.0.2 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 5, #pkts encrypt: 5, #pkts digest: 5
    #pkts decaps: 5, #pkts decrypt: 5, #pkts verify: 5
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 10.0.0.1,
     remote crypto endpt.: 10.0.0.2
     plaintext mtu 1438, path mtu 1500, ip mtu 1500,
     ip mtu idb GigabitEthernet0/0
     current outbound spi: 0x5A7B3C1D(1518558493)
     PFS (Y/N): N, DH group: none

Observe o contador de entrada e saída com 5 pacotes cada — exatamente os 5 pings que enviamos. O campo SPI (Security Parameter Index) é um identificador único gerado para esta SA IPsec e serve para indexar as políticas de segurança nos pacotes que chegam. O MTU plaintext de 1438 é esperado devido ao overhead do ESP (aproximadamente 62 bytes entre cabeçalho IPsec, ESP header/trailer e padding), e você deve ajustar o MSS via ip tcp adjust-mss nas interfaces LAN em cenários de produção para evitar fragmentação.

Erros comuns e como resolver

Em centenas de implementações de VPN com IPsec conduzidas pelos engenheiros da JRT Technology Solutions, compilamos uma lista dos erros mais frequentes que paralisam túneis. Conhecê-los antecipadamente vai poupar horas de troubleshooting.

VPN com IPsec remote access — cenário e fundamentos

Enquanto a VPN site-to-site conecta redes inteiras de forma estática e permanente, a VPN com IPsec remote access resolve o desafio de usuários móveis que precisam de acesso seguro a recursos corporativos a partir de locais imprevisíveis e com endereços IP dinâmicos. Neste cenário, o roteador central (que chamaremos de VPN-RTR) atua como servidor concentrador, enquanto o dispositivo remoto (um laptop com Cisco VPN Client, um roteador IOS configurado como cliente ou o Cisco AnyConnect) inicia a conexão. O servidor não conhece antecipadamente o IP do cliente, então precisamos de um mecanismo flexível: o crypto dynamic-map.

O crypto dynamic-map é um template que permite ao servidor aceitar conexões de peers cujos IPs não estão previamente definidos. Ele é associado a um crypto map estático como uma “última entrada” curinga, processada quando nenhuma das sequências anteriores casa com o peer. Para autenticar usuários remotos, utilizaremos o modelo aggressive mode do IKEv1 combinado com AAA local (Authentication, Authorization, and Accounting). Apesar de o aggressive mode ser menos seguro que o main mode em termos de exposição de hash, ele é necessário neste caso porque o servidor precisa autenticar o cliente por nome (não por IP fixo). Em ambientes modernos, recomendamos migrar para IKEv2 com AnyConnect, mas a configuração com IKEv1 agressivo é fundamental para compreender a evolução e para manter sistemas legados que nossos especialistas da JRT Technology Solutions ainda encontram em clientes com infraestrutura heterogênea.

Configuração do servidor VPN com IPsec remote access

O roteador servidor (VPN-RTR) possui interface WAN no IP 203.0.113.1/30 e atende a LAN corporativa 10.10.10.0/24. Os clientes VPN receberão endereços de um pool dedicado 192.168.100.0/24, atribuídos dinamicamente e comunicados ao cliente através do modo mode-config. A autenticação dos usuários será feita contra a base local do roteador. Vamos aos comandos completos, passo a passo:

! ============================================================
! SERVIDOR VPN IPSEC REMOTE ACCESS — VPN-RTR
! ============================================================

enable
configure terminal

! Habilita o serviço AAA (Autenticação, Autorização e Accounting)
aaa new-model

! Define um método de autenticação local para login
aaa authentication login VPN_AUTHENTICATION local

! Define um método de autorização para parâmetros de rede (mode-config)
aaa authorization network VPN_AUTHORIZATION local

! Cria usuários na base local
! Nota: o nome de usuário será usado como identidade IKE no modo agressivo
username usuario01 secret SenhaSegura!2026
username usuario02 secret OutraSenha@2026
username admin secret Admin#VPN2026 privilege 15

! --- Política ISAKMP (Fase 1) para remote access ---
! Usaremos grupo DH 2 (1024 bits) para compatibilidade com clientes antigos,
! mas o ideal é grupo 14 ou superior. Agressive mode é implícito
! quando usamos "pre-share" com dynamic-map e Xauth.
crypto isakmp policy 20
 encryption aes 256
 hash sha256
 authentication pre-share
 group 2
 lifetime 86400
 exit

! --- Chave pré-compartilhada curinga (0.0.0.0 0.0.0.0) ---
! Essa chave é usada para qualquer cliente que se apresentar com
! o identity correto (username).
crypto isakmp key VpnRemote_Chave2026! address 0.0.0.0 0.0.0.0

! --- Configuração do pool de endereços para clientes VPN ---
ip local pool VPN_POOL 192.168.100.1 192.168.100.50

! --- ACL para NAT exemption (se NAT estiver ativo) ---
! Permite que o tráfego entre a LAN corporativa e o pool VPN
! não seja traduzido.
access-list 150 permit ip 10.10.10.0 0.0.0.255 192.168.100.0 0.0.0.255

! --- ACL para tráfego interessante do servidor ---
! O servidor protege tráfego da LAN para o pool VPN
access-list 160 permit ip 10.10.10.0 0.0.0.255 192.168.100.0 0.0.0.255

! --- Configuração de ISAKMP para Xauth (Extended Authentication) ---
! O pool é vinculado ao nome do grupo ISAKMP (pode ser qualquer string)
crypto isakmp client configuration group VPN_GROUP
 key VpnRemote_Chave2026!
 pool VPN_POOL
 dns 8.8.8.8 8.8.4.4
 domain jrt.local
 netmask 255.255.255.0
 include-local-lan
 acl 160
 exit

! --- Transform Set para Fase 2 ---
crypto ipsec transform-set TS-REMOTE esp-aes 256 esp-sha256-hmac
 mode tunnel
 exit

! --- Crypto Dynamic Map (template) ---
crypto dynamic-map DYNMAP-VPN 20
 set transform-set TS-REMOTE
 set reverse-route
 exit

! --- Crypto Map estático que chama o dynamic-map ---
crypto map CMAP-REMOTE-VPN 20 ipsec-isakmp dynamic DYNMAP-VPN

! --- Aplicar crypto map na interface WAN ---
interface GigabitEthernet0/0
 description WAN - Internet
 crypto map CMAP-REMOTE-VPN
 ip address 203.0.113.1 255.255.255.252
 no shutdown
 exit

! --- Configurar NAT exemption (se NAT overload estiver presente) ---
! ip nat inside source list 101 interface GigabitEthernet0/0 overload
! route-map RM-NO-NAT permit 10
!  match ip address 150
! ip nat inside source route-map RM-NO-NAT interface GigabitEthernet0/0 overload

! Salvar
do write memory

O comando set reverse-route no crypto dynamic-map é uma pérola que frequentemente negligenciada: ele insere automaticamente uma rota estática para o prefixo atribuído ao cliente VPN na tabela de roteamento do servidor, usando a interface de saída do túnel como next-hop. Sem essa opção, o tráfego de retorno do servidor para o cliente pode ser roteado para a Internet ou descartado, causando a impressão de que o túnel “não funciona”. O include-local-lan no grupo ISAKMP permite que o cliente VPN acesse recursos da sua rede local simultaneamente (split tunneling deve ser desabilitado em políticas de alta segurança).

Testando e verificando a VPN com IPsec remote access

Para testar o lado servidor antes de conectar um cliente real, podemos simular o comportamento usando debug. No entanto, a validação completa requer que um cliente VPN inicie a conexão. Considerando que muitos leitores terão acesso a um roteador adicional, mostraremos a configuração mínima de um roteador cliente (R3) que atua como Cisco Easy VPN Client (EzVPN). Esta configuração é extremamente útil para testes de laboratório e prova de conceito antes de instalar softwares clientes em laptops.

! ============================================================
! CLIENTE VPN IPSEC REMOTE ACCESS — R3 (EzVPN Client)
! ============================================================

enable
configure terminal

! Interface WAN voltada para a Internet
interface GigabitEthernet0/0
 ip address 198.51.100.2 255.255.255.252
 no shutdown
 exit

! Interface LAN simulando o usuário
interface GigabitEthernet0/1
 ip address 192.168.200.1 255.255.255.0
 no shutdown
 exit

! Habilita o cliente Easy VPN
! O modo client não suporta múltiplos peers simultâneos
crypto ipsec client ezvpn VPN_REMOTE_ACCESS
 connect auto
 group VPN_GROUP key VpnRemote_Chave2026!
 mode client
 peer 203.0.113.1
 username usuario01 password SenhaSegura!2026
 xauth userid mode local
 exit

! Aplica o cliente na interface WAN
interface GigabitEthernet0/0
 crypto ipsec client ezvpn VPN_REMOTE_ACCESS
 exit

! Rota padrão apontando para o next-hop da Internet (para alcançar o servidor)
ip route 0.0.0.0 0.0.0.0 198.51.100.1

! Ativa a conexão automaticamente com tráfego interessante
! Basta um ping da LAN do cliente para a LAN do servidor
! ping 10.10.10.1 source GigabitEthernet0/1

do write memory

Para verificar a conexão no servidor VPN-RTR após o cliente se conectar, utilize os mesmos comandos de verificação que empregamos na VPN site-to-site, porém prestando atenção a novos detalhes específicos de ambientes dinâmicos:

! No servidor VPN-RTR:
show crypto session detail
show crypto isakmp sa
show crypto ipsec sa | include ident|current_peer|pkts
show ip route static
show ip local pool VPN_POOL

A saída esperada para show crypto session detail deve listar o peer dinâmico recém-conectado, seu username autenticado via Xauth, e o IP virtual atribuído do pool:

Crypto session current status

Interface: GigabitEthernet0/0
Session status: UP-ACTIVE
Peer: 198.51.100.2 port 500
  IKE SA: local 203.0.113.1/500 remote 198.51.100.2/500 Active
  IPSEC FLOW: permit ip 10.10.10.0/255.255.255.0 192.168.100.1/255.255.255.255
        Active SAs: 2, origin: crypto map
  Group: VPN_GROUP
  Username: usuario01
  Assigned IP: 192.168.100.1

O comando show ip local pool VPN_POOL exibe quais endereços do pool estão em uso e qual usuário os está utilizando — informação valiosa para auditoria e troubleshooting de conflitos de IP. Em nossos projetos na JRT Technology Solutions, sempre deixamos um script de monitoramento que executa esse comando periodicamente e gera alertas caso o pool atinja 80% de utilização.

Comandos de debug para troubleshooting aprofundado em VPN com IPsec

Quando os comandos show não são suficientes para diagnosticar uma falha, os debugs entram em cena. Contudo, debugs de IPsec são extremamente verbosos e podem sobrecarregar a CPU de roteadores em produção. Sempre isole o tráfego que deseja inspecionar usando debug condition baseado no IP do peer, e nunca deixe debugs rodando indefinidamente — use undebug all ou no debug all após a coleta. Os comandos essenciais:

Uma técnica avançada que usamos na JRT Technology Solutions é combinar debug crypto isakmp com term mon (quando em SSH/Telnet) e logging buffered 100000 debugging, redirecionando a saída para o buffer e depois analisando com show logging. Isso evita que a sessão interativa seja inundada e permite buscar padrões com pipes (| include).

Boas práticas e hardening de VPN com IPsec no Cisco IOS

A configuração funcional é apenas o começo. Para alcançar um nível profissional de implementação, você deve adotar as práticas de hardening que tornam seus túneis resistentes a ataques e tolerantes a falhas. A primeira delas é a escolha de algoritmos fortes: sempre que possível, abandone completamente o DES, 3DES, MD5 e SHA-1. Use AES-256 (ou AES-128-GCM para desempenho em hardware mais antigo) e SHA-256. Em relação ao Diffie-Hellman, o grupo 14 (2048 bits) é o mínimo aceitável; grupos 19 e 20 (curvas elípticas) são recomendados em equipamentos modernos que suportam o comando group 19 na política ISAKMP.

Perfect Forward Secrecy (PFS) merece atenção especial. Quando habilitado na Fase 2 (set pfs group14 dentro do crypto map), uma nova troca Diffie-Hellman é realizada a cada renovação de SA IPsec, garantindo que a chave de sessão não seja derivada da chave da Fase 1. Isso significa que, mesmo que um atacante comprometa a chave de longa duração, as sessões passadas permanecem seguras. O custo é um pequeno acréscimo de latência na renegociação — imperceptível para a maioria das aplicações, mas crítico em cenários de alta densidade de túneis.

Outro aspecto frequentemente negligenciado é o tratamento de MTU e fragmentação. O overhead do IPsec (cabeçalho IP adicional + header ESP + IV + trailer + padding) pode adicionar entre 50 e 73 bytes ao pacote original. Se um pacote de 1500 bytes da LAN tentar atravessar o túnel, ele será fragmentado antes da criptografia — um processo chamado pre-fragmentation — aumentando a latência e as chances de perda. A solução elegante é ajustar o TCP MSS para 1360 bytes (ou menos, dependendo do cenário) nas interfaces LAN de ambos os lados, com o comando:

interface GigabitEthernet0/1
 ip tcp adjust-mss 1360

Nossos especialistas da JRT Technology Solutions também recomendam enfaticamente que você configure monitoramento proativo dos túneis. Uma técnica simples é um script que executa show crypto ipsec sa | include pkts a cada 5 minutos. Se os contadores de encaps/decaps permanecerem zerados por vários intervalos, um alerta deve ser gerado. Para ambientes de produção, considere o uso de IP SLA com operação ICMP Echo através do túnel e track objects que disparam rotas de backup ou notificações SNMP. O Cisco IOS suporta ip sla nativamente e sua integração com track é matéria que exploraremos em aulas avançadas.

Por fim, quanto ao NAT traversal (NAT-T): se algum dos peers estiver atrás