Minha jornada até o CCIE RS — DMVPN 1

Quase um Rembrandt

E aí pessoal, tudo bem?

Continuando esta série de artigos, compartilho minhas anotações acumuladas durante anos de trabalho e estudos. Até passar no CCIE RS foram quase 400 páginas de cadernos com informações e observações que considero importantes ao trabalhar com Routing and Switching por quase 15 anos.

Sempre digo, acredito que estas informações possam ajudar não só para passar em certificações, mas no dia-a-dia de outros engenheiros como eu a lidar com infraestrutura de redes.

Para quem não leu os artigos anteriores da série, seguem os links sobre “Switching”, “PPP”, “IP Routing”, “RIP”, “EIGRP”, “OSPF”, “BGP” e “Redistribuição” e “MPLS”.

Neste e nos próximos artigos falaremos sobre DMVPN. DMVPNs podem ser implantadas de 1001 formas. Portanto, para chegarmos ao ponto em como DMVPNs são utilizadas hoje, precisamos explicar alguns pontos básicos. O IPsec fornece a base para DMVPNs seguras.

Hoje exploraremos os pontos-chave sobre IPsec VPN, como testar e ao final uma lista de comandos “show” + filtros que considero eficiente.

Fique a vontade para comentar e entrar em contato comigo no LinkedIn. Se gostou do que leu, incentivo a compartilhar com colegas do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow lá em cima :)

IPsec VPN

Principais funções são autenticar e encriptar IPv4 e IPv6.

Forma túneis P2P e, portanto, entre cada spoke-HUB ou spoke-spoke há um túnel (com SAs separadas).

Túneis são dinamicamente negociados através de IKE (ISAKMP).

• Principal objetivo é não definir as crypto keys manualmente.

ISAKMP/IKE são os protocolos de negociação usados para formar as SAs (Security Associations).

Negociação

Objetivo do IPsec Exchange é estabelecer SA.

IPsec PHASE 1

• Autentica os endpoints e constrói um túnel seguro para prosseguir com a negociação.
• Resulta no ISAKMP SA.

IPsec PHASE 2

• Estabelece um túnel usado para proteger o data-plane (tráfego).
• Resulta no IPsec SA.

PHASE 1

Peers devem concordar em 4 parâmetros:

• Autenticação: PSK (pre-shared key) ou Certificados (CA)
• DF group: Determina a força da key (PKI) (1/2/5…)
• Tipo da encriptação: DES, 3DES, AES
• Algoritmo hash: MD5, SHA1…

Diffie Hellman Group

• Quão amplo é o range que temos para gerar o primo que gerará a chave do algoritmo de criptografia.
• — Diffie-Hellman — wikipedia
• Determina a força da key. Quanto maior melhor (e mais usa CPU).
• O resultado do DH são as chaves simétricas usadas pelo métodos de encriptação.

OBS: Criptografia é o estudo, enquanto encriptação é o processo. Você encripta alguma informação :) Atualmente criptografar já está no dicionário.

IKE Hash

• Hash usado para autenticar o pacote
• Depende da versão do IKE
• — IKEv1 — MD5 e SHA1
• — IKEv2 — SHA-256, SHA-384, etc

ISAKMP Policy é a combinação dos parâmetros IKE. Quando os peers concordam com os parâmetros, um túnel encriptado é formado e através dele ocorre a negociação da PHASE 2.

Configuração PHASE 1

• Crie política com número 10–100 de forma que consiga criar outras mais prioritárias depois.
• Autenticação:
• — pre-share — <cry isa key ABC address x.x.x.x>
• — rsa-sig — PKI/CA (certificado)
• — rsa-encr — legado e não usado
• Hashing:
• — sha -> conhecido como sha1 (160 bits)
• DH

A chave deve ser especificada por IP de origem do peer. Se o peer possui múltiplas interfaces de origem ele pode utilizar múltiplos source-address por default, portanto é interessante manipular manualmente e manter apenas um (ex: loopback). O uso de túneis + IPsec facilita este processo porque usa a interface do túnel (ver mais além).

PHASE 2

Definindo PHASE 2 IPsec Policy

IPsec Policy define 3 atributos principais:

• Who?
• — endereço do peer, hostname ou FQDN
• What?
• — Proxy ACLs
• How?
• — Transform set

Peers devem concordar com os parâmetros (IPsec Transform Set):

• Security Protocol — encapsulamento ESP ou AH
• Encapsulation Mode — tunnel ou transport
• Encriptação — DES, 3DES, AES
• Autenticação — MD5, SHA, SHA-256, etc

Security Protocol

• AH
• — Protocolo 51
• — Não suporta encriptação (geralmente não é usado)
• ESP
• — Protocolo 50
• — Suporta encriptação

Encapsulamento

• Transport
• — Usa cabeçalho IP original.
• — Geralmente usado entre hosts (na mesma rede).
• Tunnel
• — Adiciona um novo cabeçalho IP.
• — Tipicamente usado entre gateways IPsec (em redes diferentes).

PHASE 2 também negocia:

• Proxy Identities — define o tráfego interessante a ser encriptado, também chamado de Proxy ACLs.
• Security Association (SA) Lifetime — frequência do re-keying.
• Perfect Forwarding Secrecy (PFS) — devemos renegociar DH antes de re-key ou usar original?

Proxy Identities (Proxy ACLs)

• Tráfego interessante que ativa o túnel.
• Proxy ACLs devem ser imagens espelhadas exatas. Se não forem exatamente opostas, o túnel falha na negociação.

SA Lifetimes

• ISAKMP SA e IPsec SA tem vida finita.
• Antes de expirar elas são re-keyed.
• Lifetime pode ser tempo ou bits.
• Menor valor entre os peers é negociado.
• Re-keying utiliza o DH original ou novo dependendo se o PFS está ativo:
• — sem PFS -> DH original
• — com PFS -> gera novo DH

IPsec Control-plane e Data-plane

IPsec control-plane

• udp 500
• udp 4500 se usar NAT

IPsec data-plane

• ESP (500) ou AH (51)
• ESP over UDP 4500 se usar NAT

Default Policies para PHASE 1 e 2

• Default ISAKMP Policies permanecem ativas até que novas policies sejam criadas. Podem ser desabilitadas com <no crypto isakmp default-policies>.
• Default IPsec Transform-sets permanecem ativos se nenhum transform-set criado tenha sido aplicado. Pode ser desabilitados com <no crypto ipsec transform-set default>.

OBS: Não é porque as Policies foram criadas, aplicadas e o túnel subiu que as Policies funcionaram. A negociação pode ter realizado fallback para as Default Policies. Para ter certeza que funcionaram é necessário checar quais estão em uso.

OBS: Crypto-key com destino 0.0.0.0 é wildcard para “todos”.

IPsec VPN — Crypto Maps

• Método antigo.
• Principal limitação é não suportar IGP dinâmico diretamente. Precisa de um túnel GRE para suportar, sobre o IPsec.
• Crypto-map é um filtro de data-plane cujo tráfego interessante ativa sessão ISAKMP. O tráfego interessante é definido pelas ACLs que compõem o Proxy ID para PHASE 2.
• Crypto-map é aplicado diretamente na (sub)interface e funciona sempre outbound, de forma que o IP de origem do túnel será o IP da interface por default.

Modos de Crypto-map:

• IPsec — isakmp — Usado 99% das vezes. Especifica que a chave gerada pelo ISAKMP será usada para encriptar e decriptar.
• IPsec — manual -> Não usar. Especifica que a chave será definida manualmente.
• gdoi -> GETVPN

Crypto-map deve ser aplicado na interface mais próxima do destino (na interface que retorna no <sh ip route x.x.x.x>). Se houver múltiplas interfaces mais próximas, crypto-map deve ser aplicado em todas.

OBS: Processos de Roteamento, NAT e Encriptação são sempre independentes entre si. Encriptação sempre opera depois do roteamento e NAT.

• Rotas estáticas podem ser necessárias.
• Entradas NAT podem ser necessárias.

OBS: É possível utilizar um object-group para facilitar a configuração, mas é difícil achar um cenário prático. Geralmente GRE over IPsec ou VTY tunnel simplifica tanto a config que não há mais lugar para crypto-map.

Se por alguma razão específica (ex: questão do lab CCIE) exige trasportar tráfego muito específico talvez seja necessário usar GRE ou Policy Routing.

Passos:

• Definir ISAKMP Policy (PHASE 1)
• Definir IPsec Policy (PHASE 2)
• Aplicar Crypto-map
• Gerar tráfego interessante

ISAKMP Policy

Policies são processadas Top-Down, de forma que devemos ir da mais segura para a menos segura. Parâmetros:

• Autenticação
• Encriptação
• Hash
• DF
• Lifetime

IPsec Policy

• Who? — peer address
• What? — proxy ACL
• How? — transform-set

Exemplo: no transform-set “esp-aes esp-md5-hmac”:

• esp é encapsulation
• aes é encryption
• md5 é hashing

A nomenclatura (nome) do crypto-map deve ser especificada de forma a exibir seus parâmetros para facilitar (ex: ESP-AES-128-MD5).

Exemplo de nomenclatura prática para transform-set: “ESP_AES_192_SHA1”.

• encapsulamento — AH ou ESP
• encriptação (cypher) — AES, DES, 3DES, etc
• hashing (HMAC) (autenticação) — MD5 ou SHA

OBS: <sh run brief | se crypto|isakmp|access-list> exclui o certificado e exibe tudo relacionado a IPsec.

<sh cry isa sa>

• Repare que src e dst devem estar corretas nos peers.
• ISAKMP SA — State deve mostrar QM_IDLE (quick mode) e status Active.
• QM = “quick mode -> go to PHASE 2”
• Qualquer coisa diferente de QM, não funcionou (ex: Main mode ou aggressive mode)

<sh cry ip sa>

• Pacotes sendo “encap” e “decap” (encapsulamento), “encrypt” e “decrypt” (encriptação) e “digest” e “verify” (autenticação).
• Acordo sobre o tratamento do data-plane
• Deve mostrar 2 túneis one-way e por isso 2 SAs (inbound e outbound)
• Verificar as linhas “packets encaps” e “packets decaps” incrementando.
• crypto-map é on-demand, então se não houver tráfego, o túnel expira a negociação e cai.
• Local ident = Proxy ID
• port — UDP 500
• errors = 0 -> está funcionando
• SPI é o número de sequência do túnel. Quando o pacote é recebido, é o SPI que determina para qual túnel é o pacote (como VLAN tag). SPI é a tag do data-plane.
• Tunnel mode adiciona header variável. O cálculo do tamanho é difícil pois é baseado no cipher e o cipher é baseado no payload!!
• — OBS: Para descobrir overhead use <ping df-bit 1500> e desça até descobrir valor de sucesso. A diferença será o overhead.

Captura de pacotes IPsec

• Pacotes ISAKMP podem ser analisados (parâmetros iniciais) e por isso a negociação IPsec ocorre dentro do túnel ISAKMP encriptado.
• Pacotes ESP só mostram: túnel, IP origem, IP destino, SPI (sequência) e payload encriptado.

OBS: Transport mode foi desenvolvido para host-to-host (na mesma LAN) e tunnel mode deveria rodar entre routers (redes diferentes). Mesmo que o router seja configurado em transport mode, ele pode forçar o fallback para tunnel mode porque transport mode só é permitido em cenários específicos como GETVPN.

Para deletar tunnel:

• <clear cry sa> — PHASE 2
• <clear cry isa> — PHASE 1

DOC: https://packetpushers.net/ipsec-bandwidth-overhead-using-aes/

• Bom artigo da Packet Pushers mostrando sobre fragmentação dos pacotes IPsec, padding, etc.

Verificação de IPsec

Principal problema com IPsec é que há muitas formas de se cometer pequenos enganos e 99% deles quebram a config do túnel.

PHASE 1 utiliza um túnel bidirecional UDP, enquanto a PHASE 2 utiliza 2 túneis unidirecionais UDP.

Aplicando debug geralmente leva 1–2 minutos para resolver. Bem mais rápido que ficar caçando na config.

Passos importantes:

• Entender como verificar e realizar troubleshooting
• Interpretar debug

Phase 1

• <sh cry isa sa [detail]> — Deve mostrar QM_IDLE e status ACTIVE. Qualquer coisa diferente implica erro.
• <debug cry isa> — Mostra processo de negociação.
• — OBS: Debug gera muitas mensagens e é sempre recomendado mandar para buffer ou tacacs.
• <debu cry condition peer ipv4 X.X.X.X> — restringe os debugs para peers relevantes (imagine múltiplas VPNs e a zona que seria 😛)

Passos

• Autenticação está funcionando?
• — Checar PSK/CA
• — Mensagens relacionadas a autenticação não são diretas
• — Falha pode significar pacote corrompido
• Atributos do IKEv1 SA match?
• — Razoavelmente fácil de diagnosticar porque os debugs apontam diretamente os atributos acceptable e unacceptable.
• Resultado final deve ser um ISAKMP SA bidirecional.

OBS: <debug cry isa> gera muitas mensagens. Assim como outros debugs, é aconselhável usar buffer ou syslog.

#logging console 6 — tudo menos debug

#logging buffer 7

#logging buffer 999999

#clear log

OBS: Debugs são necessários em ambos os peers porque as saídas são diferentes dependendo se é iniciador ou receptor. O iniciador envia um ISAKMP proposal. O receptor compara a ISAKMP policy com as suas e somente ele mostra porque rejeitou. Resumindo, apenas o Responder importa.

Saídas do debug com sucesso:

“atbs are acceptable”

“SA authentication status: authenticated”

“begining Quick Mode exchange” (phase 2)

“ISAKMP: IKE_P1_COMPLETE” significa que PHASE 1 concluiu com sucesso.

Phase 2

• Ao checar IPsec SA, o resultado deve ser 2 SAs por entrada na ACL (inbound e outbound).
• Contadores incrementando de forma unidirecional geralmente significam problema no data-plane (ex: alguém filtrando ESP).
• Assim como na PHASE 1, o debug especifica diretamente quais atributos são acceptable e quais são non-acceptable.
• Somente depois das primeiras mensagens “IPsec:” no debug é que o túnel está criptografado e negociando PHASE 2.

Debug exibe informações de:

• Who — peers
• What — Proxy Identities
• How — Transform-sets

Saídas do debug:

• “sa created”
• “IKE_QM_PHASE2_COMPLETE” -> mensagem final \o/

Problemas

PHASE 1

Comandos show só servem para verificar se funcionou. Se não funcionou, os comandos show não mostram nada e troubleshooting deve ser realizado através de debug.

OBS: Debug no iniciador não mostra nada sobre PHASE 2 e também não informa o motivo da falha. Isso porque o receptor não informa o motivo da falha na negociação para evitar um ataque brute force. Não mostra nada além de retransmissões repetitivas.

Mensagens:

• “transform X against priority Y policy” — X é a ISAKMP Policy recebida e Y é a local.
• “no offers accepted!” -> nenhuma policy deu match

Depois que constatar os parâmetros diferentes, devemos comparar com as local policies e corrigir.

• <sh cry isa policy>
• <sh cry ipsec policy>

Com relação a autenticação, não há mensagem direta informando se a chave está correta ou errada porque a chave não é trocada. O router apenas informa que o hashing do pacote inteiro não bateu (hashing formado com a key).

• “failed its sanity check or is malformed” -> geralmente erro de autenticação
• “MM_KEY_EXCHANGE” significa travado na parte de autenticação (KEY).

Se “state = QM_IDLE”, PHASE 1 está OK e problema é PHASE 2 (IPsec), a última mensagem do debug deve ser “SA authentication status: authenticated”.

PHASE 2

How:

• “NOTIFY PROPOSAL_NOT_CHOSEN” no iniciador significa falha na PHASE 2 mas não se sabe o quê.
• Se o problema for o Transform Set do lado do receptor, o router não informa qual parâmetro não bate, apenas “transform proposal not supported”. Basta compará-los <sh cry ip transform-set>.

What:

• “Proxy identities not supported” -> ACLs estão erradas. Falha muito comum copiar ACLs iguais nos dois peers. Elas devem ser espelhos.

Resumo:

• Transform sets não batem? -> “NOTIFY PROPOSAL_NOT_CHOSEN”
• ACLs não são espelhadas? -> “proxy identities not supported”
• Resultado deve ser 2 SAs por ACL (inbound e outbound). Se pacotes são encapsulados de um lado mas não são desencapsulados do outro existe um problema no data-plane (ex: túnel funciona de forma unidirecional) (ex: filtro no caminho).

OBS: Se habilitou debug ISAKMP e IPSEC e não aparece mensagem nenhuma, muito provavelmente é falha de roteamento ou NAT, pois estes ocorrem antes.

Comandos Show para IPsec VPN

ISAKMP e IPsec

• sh cry isa key — pre-shared keys para autenticação
• sh cry isa po — PHASE 1 Policies
• sh cry isa sa — Status PHASE 1
• sh cry isa sa det
• sh cry isa peer
• sh cry map [int] — config final do crypto map
• — OBS: informa se a config está incompleta.
• sh cry ip pro
• sh cry ip trans — PHASE 2 Policies
• sh cry ip sa — Status PHASE 2 — Mostra SA in e SA out.
• sh cry ip sa | in ident|caps
• sh cry ip sa | in ident|esp|spi
• sh cry debug condition — filtros de debug (geralmente usado por peer)
• debug cry isa
• debug cry ipsec
• debug crypto condition peer ipv4 X.X.X.X
• <debug dmvpn all> basicamente a combinação de <debug nhrp> e <debug crypto>

Mostram o resultado das negociações:

• sh cry isa sa
• sh cry ip sa

Mostram exatamente o que houve de errado e precisa saber interpretar:

• debug cry isa
• debug cry ipsec

O que achou deste artigo sobre DMVPN?

Esse artigo te ajudará no dia-a-dia?

Fala pra gente nos comentários?

Se gostou do conteúdo, peço para compartilhar com outros do ramo. Não se esqueça de seguir a mim e ao TechRebels clicando follow aí embaixo :)

Sobre o autor:

Giuliano Barros é Network Engineer & Founder da Control Plane — Network Services.

Graduado em Ciência da Computação, certificado CCIE RS e Cisco Champion 2019 pela Cisco Systems, trabalha há 15 anos como Network Engineer em projetos para grandes e médias empresas. linkedin.com/in/giulianobarros