Os níveis de acesso utilizando CLI do FTD e FXOS

Neste post estarei apresentando um resumo sobre os níveis de acesso utilizando a CLI no Firewall FTD e FXOS, quero apresentar as possibilidades que podem ser utilizadas para realizar análise de configurações, debugs e troubleshooting.

Fluxo de navegação FTD CLIcli ftd

Presumindo que vc esteja na CLI do FXOS, execute o seguinte comando para se conectar ao Security Module onde o software FTD está instalado, neste exemplo estou utilizando o FTD 4110.

Firepower-4100# connect module 1 console
Telnet escape character is ‘~’.
Trying 127.5.1.1…
Connected to 127.5.1.1.
Escape character is ‘~’.
CISCO Serial Over LAN:
Close Network Connection to Exit
Firepower-module1>

Partindo da mesma ideia que agora você está na CLI do Security Module. Execute o comando abaixo para se conectar à CLI do FTD:

Firepower-module1>connect ftd
Connecting to ftd console… enter exit to return to bootCLI
>

Está informação >  indica que você está na CLI do FTD todas as tarefas executadas aqui são relacionadas ao FTD. Se você quiser alterar para o console do ASA, precisamos executar outro comando para trocar de CLI.

> system support diagnostic-cli
Attaching to ASA console … Press ‘Ctrl+a then d’ to detach.
Type help or ‘?’ for a list of available commands.
firepower>

Agora, você está na CLI do ASA. Execute o seguinte comando para acessar o modo privilegiado. Será solicitada a senha de enable.

firepower> enable
Password:
firepower#

Para sair do console ASA, pressione ‘Ctrl + a depois d’.

firepower#
Console connection detached.
>

Espero que possa ser útil para alguém.

Reflexão mimimi

Sim, é isso mesmo chega de mimimi, vamos estudar mais, trabalhar mais e agradecer mais!

Eu vejo no dia a dia muitas pessoas reclamando, reclamando e reclamando sobre tudo, eu escuto muito…Poxa cara!…Mas é difícil dedicar parte do meu tempo para estudar, eu só tenho os finais de semana para relaxar, entendo e concordo que é complicado trabalhar a semana inteira e chegar ao fim de semana e ter que estudar para aquela certificação difícil, aquele trabalho complicado, vejo reclamações orra! Essas coisas só acontecem comigo, as pessoas deste ambiente são isso ou aquilo. Enfim, muito mimimi e pouca ação, vamos lá, precisamos parar de reclamar e agradecer mais, por nosso trabalho, nossa vida, nossa saúde, correr atrás dos objetivos que você almeja alcançar.

Nada na vida é fácil, eu gosto de encarar tudo que acontece nela como desafios, na verdade, tudo é um desafio, um objetivo, metas ou sonhos e cada conquista é uma vitória é um eterno recomeçar, porque precisamos sempre ter sonhos e metas, acredito que isso é o combustível que nos faz acordar todos os dias para encarar a vida e ter vontade de vencer e sempre tentar ser melhorar do que ontem.

Não mais mimimi 

mimimi-everywhere-toystory

Então, borá estudar, trabalhar e acreditar que nada é impossível, você e somente você é o único responsável por tudo que acontece na sua vida!

 

 

Cisco Champion 2018

Yes, we are! We are Cisco champion 2018!

n30ine

É com alegria que recebo este título de Cisco Champion 2018, obrigado pelo reconhecimento, estou muito feliz e grato por ser membro deste programa.

CiscoChampion

Para aqueles que ainda não conhecem o programa, este é um título de reconhecimento que a Cisco oferece para aquelas pessoas que gostam compartilhar seu conhecimento, experiência e pensamentos na web, redes sociais e com a Cisco. O programa Cisco Champion engloba várias áreas, como Data Center, Enterprise Networks, Collaboration e Security. É uma grande oportunidade para aumentar o networking e ajudar outras pessoas.

 

BUG CVE-2018-0101 – VPN Anyconnect RA

A Cisco anunciou no dia 29 de janeiro de 2018 uma falha que pode ser explorada no ASA ou FTD quando a configuração de VPN Anyconnect Remote Access está configurada.

ASA-BUG

A vulnerabilidade pode ser explorada quando o recurso de webvpn está habilitado no  Cisco ASA. O atacante pode explorar essa vulnerabilidade enviando pacotes XML para a interface configurada no webvpn no sistema afetado. Com a utilização de um exploit o atacante ganha acesso para executar códigos maliciosos e obter o controle total do Cisco ASA ou FTD e pode causar uma sobrecarga do dispositivo afetado fazendo com que ele seja reiniciado.

Os dispositivos que foram afetados com esta falha são:

  • 3000 Series Industrial Security Appliance (ISA)
  • ASA 5500 Series Adaptive Security Appliances
  • ASA 5500-X Series Next-Generation Firewalls
  • ASA Services Module for Cisco Catalyst 6500 Series Switches and Cisco 7600 Series Routers
  • ASA 1000V Cloud Firewall
  • Adaptive Security Virtual Appliance (ASAv)
  • Firepower 2100 Series Security Appliance
  • Firepower 4110 Security Appliance
  • Firepower 9300 ASA Security Module
    Firepower Threat Defense Software (FTD)

Workarounds
Nenhum workaround para abordagem desta vulnerabilidade foi disponibilizado é necessário a atualização do ASA ou FTD.

Releases com as correções para Cisco ASA

ASA

Correção para Cisco FTD

ftd

Para aqueles que foram afetados e estão utilizando ASA ou FTD, é extremamente importante a atualização do sistema.

Cisco Anyconnect Remote Access

Neste artigo, estarei descrevendo os procedimentos para configuração do cliente de VPN Anyconnect para o Firewall ASA.

Annyconnect é o substituto do antigo cliente VPN para Remote Access, ele suporta dois modos de configurações para o ASA, SSL e IPsec IKEv2.

  • Clientless WebVPN
  • AnyConnect VPN

Clientless WebVPN: Este modo de configuração não depender que um software de cliente VPN seja instalado na máquina do usuário, ele é útil quando os usuários remotos desejam estabelecer uma conexão segura com o ambiente corporativo, mas não possuem direitos administrativos  no PC. O Webvpn fornece conectividade de acesso remoto a partir de quase qualquer local com acesso para Internet usando apenas um navegador da Web.

Para acesso a VPN SSL apenas é necessário abrir o navegador, inserir o endereço IP externo do ASA e você terá acesso através de um portal Web. Alguns acesso são limitado, por exemplo:

  • Internal websites (HTTP and HTTPS)
  • Web applications
  • Windows file shares
  • Email servers (POP3, IMAP, SMTP)
  • Microsoft Outlook Web Access

VPN RA

Quando utilizando WebVPN não há acesso completo à rede, apenas com o software Anyconnect VPN que oferece acesso completo à rede. O usuário remoto usará o cliente anyconnect para se conectar ao ASA e receberá um endereço IP de um pool de VPN permitindo acesso total à rede.

Drawing34

Acima temos o ASA com duas zonas de segurança: Outside e Inside. O usuário remoto está localizado em qualquer lugar do lado de fora da rede corporativa e quer acesso remoto com o cliente Anyconnect que está instalado em sua máquina, vamos dar uma olhada nas configurações em como podemos permitir que nosso amigo se conecte na VPN e tenha acesso ao ambiente “Corporate LAN”.

CONFIGURAÇÃO DO ASA

Basicamente podemos resumir a configuração da VPN Anyconnect no ASA em algumas etapas, seguem elas.

  • Carregar a imagem do cliente SSL VPN dentro da Flash do ASA
  • Habilitar AnyConnect VPN
  • Customizações
  • Endereços POOL VPN
  • Configuração Split-Tunel
  • Criar uma Política de Grupo
  • Criar perfil de conexão do túnel
  • Configurar contas de usuário

Passo1: Imagens software Anyconnect
Usuários remotos que não tiverem o sofware de VPN Anyconnect instalado em sua máquina, poderá baixar o cliente do ASA, é preciso fazer o upload das imagens para o Firewall, estas imagens são armazenadas na Flash, cada sistema operacional tem um tipo especifico de arquivo.

ASA-1# show flash:
112 31522773 Dec 11 2018 15:01:52 anyconnect-linux64-4.5.02033-webdeploy-k9.pkg
113 9993060 Dec 11 2018 15:06:50 anyconnect-macos-4.5.02033-webdeploy-k9.pkg
114 11293375 Dec 11 2018 15:08:34 anyconnect-win-4.5.02033-webdeploy-k9.pkg

Passo2: Habilitar AnyConnect VPN

# webvpn
# enable OUTSIDE
# anyconnect image disk0:/anyconnect-linux64-4.5.02033-webdeploy-k9.pkg
# anyconnect image disk0:/anyconnect-macos-4.5.02033-webdeploy-k9.pkg
# anyconnect image disk0:/anyconnect-win-4.5.02033-webdeploy-k9.pkg
# tunnel-group-list enable
# anyconnect enable

Passo3: Customizações
SYSOPT
Quando você possui uma lista de acesso de entrada na interface OUTSIDE, todo o tráfego decriptado de SSL WebVPN deve corresponder à uma access-list ACL de entrada. O seguinte comando informa ao ASA para permitir que esse tráfego ignore a ACL.

# sysopt connection permit-vpn

HTTP redirecionamento para HTTPS
Usuários remotos precisam especificar o protocolo HTTPS para se conectar a WebVPN, esta customização é opcional. mas muito útil porque sempre que alguém acessar o ASA utilizando HTTP será redirecionado para HTTPS.

# http redirect OUTSIDE 80

Passo4: Configuração endereço POOL VPN
O ASA atribuirá endereços IPs aos usuários remotos que se conectem com o Anyconnect. Os usuários remotos receberão um endereço IP do pool de intervalo de endereços 192.168.10.5-20.

# ip local pool VPN-POOL 192.168.5.1-192.168.5.20 mask 255.255.255.0

Passo5: Split-Tunnel
Por padrão, todo o tráfego será enviado através do túnel VPN uma vez que o usuário remoto esteja conectado. Para permitir que usuários remotos acessem a Internet ou recursos da sua rede local, é preciso configurar um regra de split-tunel que especifique quais redes queremos alcançar através do túnel.

# access-list SPLIT-TUNEL-VPN standard permit 192.168.1.0 255.255.255.0
*** Esta configuração informa o tunel somente será utilizado para alcançar a Rede 192.168.1.0/24.

Passo6: Group-Policy
Um group-policy é um perfil de conexão que usa políticas que define condições para conexões de usuário após o túnel ser estabelecido. As políticas de grupo permitem que sejam aplicas atributos para um usuário ou um grupo de usuários.

Configuração de Group-Policy
# group-policy GROUP-POLICY-1 internal
# group-policy GROUP-POLICY-1 attributes
#  dns-server value 208.67.222.222 208.67.220.220
#  default-domain value labccie.local
#  split-dns value labccie.local
#  vpn-tunnel-protocol ssl-client ssl-clientless
#  split-tunnel-policy tunnelspecified
#  split-tunnel-network-list value SPLIT-TUNEL-VPN
#  webvpn
# anyconnect keep-installer installed
# anyconnect ask none default anyconnect
# anyconnect dpd-interval client 30

Passo7: Configuração Tunnel-group
O tunnel-group é utilizando quando é necessário usar regras diferentes para cada tipo de usuários. Por exemplo, um grupo pode ter regras para conectar mais de 20 usuários ao mesmo tempo, 20 minutos de inatividade, e ter acesso apenas ao servidor de e-mail. E outro grupo pode ter acesso a todos os servidores, tem um tempo de inatividade de 60 minutos, ou quando se esta utilizando servidores externo para autenticação, Radius, AD, LDAP, etc.

ASA-1(config)# tunnel-group CORPORATIVO type remote-access
ASA-1(config)# tunnel-group CORPORATIVO general-attributes
!
ASA-1(config-tunnel-general)# default-group-policy ANYCONNECT_POLICY
ASA-1(config-tunnel-general)# default-group-policy GROUP-POLICY-1
ASA-1(config-tunnel-general)# address-pool VPN_POOL
!

Quando usuários remotos se conectarem, o ASA mostrará um nome de grupo que pode ser customizado de acordo com o ambiente, para esta configuração foi utilizado o nome CORPORATIVO.
ASA-1(config)# tunnel-group CORPORATIVO webvpn-attributes
ASA-1(config-tunnel-webvpn)# group-alias CORPORATIVO enable
!
Passo8: Usuários para VPN
Esta configuração estamos utilizando a base local de usuários para conectar na VPN Remote Access, o ASA permite integração com servidores externos como AD, LDAP, ISE e Radius.

Criar as contas de usuários para acesso a VPN
ASA-1(config)# username teste-vpn password cisco@123

Precisa informar ao ASA que este usuário tem permissão para autenticar na VPN.
ASA1(config)# username teste-vpn attributes
ASA1(config-username)# service-type remote-access

Basicamente o que é necessário após está configuração no Firewall ASA é instalação do cliente Anyconnect na máquina do usuário, e apontar o endereço externo do ASA 100.100.100.1. Será solicitado um Login/Senha, configurado no Passo8.

Para Tshoot e verificações, abaixo alguns comandos que eu utilizo muito.

ASA-1# show vpn-sessiondb ASA-1# show vpn-sessiondb
Session Type: SSL VPN Client
Username     : teste-vpn
Index             : 1                                   IP Addr           : 192.168.5.3
Protocol        : SSL VPN Client          Encryption    : 3DES
Hashing        : SHA1                           Auth Mode     : userPassword
TCP Dst Port : 443                    TCP Src Port : 54230
Bytes Tx        : 20178                  Bytes Rx     : 8662Pkts Tx      : 27                  Pkts Rx      : 19
Client Type   : Internet Explorer
Group            : GROUP-POLICY-1
Login Time   : 14:32:03 UTC Wed Mar 20 2007
Duration       : 0h:00m:04s
Inactivity      : 0h:00m:04s
Filter Name  :

ASA-1# vpn-sessiondb logoff
INFO: Number of sessions of type “” logged off : 1

ASA-1# vpn-sessiondb logoff name teste-vpn
Do you want to logoff the VPN session(s)? [confirm]
INFO: Number of sessions with name “teste-vpn” logged off : 1

Como reiniciar console de gerenciamento do FMC?

Este documento descreve como reiniciar os serviços em um appliance Cisco FMC com a utilização da Interface gráfica ou através da CLI.

Reiniciar os processos de gerenciamento do FMC

Dependendo do problema que você se deparar pode ser necessário reiniciar os processos e serviços que são executados no FMC.
Podemos reiniciar esses serviços e processos sem a necessidade de reinicie todo o Firepower, conforme estarei apresentando nas seções que se seguem.

Passos para reiniciar os processos através da interface WEB
Abaixo relacionei as etapas para reiniciar os processos do FMC através da interface Web:

Passo1: Faça login na interface Web do FMC
Passo2: Em System > Local > Configuration > Process

FMC
Clique em  Run Command para Restart Defense Center Console. Isso reinicia os serviços e processos.

Reiniciar os processos com a CLI
Abaixo relacionei as etapas para reiniciar os processos do FMC através da CLI:

Passo1: Faça login na CLI do FMC

Passo2: Elevar seu nível de privilégio para o modo de usuário raiz
admin@ccielab-fmc:~$ sudo su –

Passo3: Digite este comando na CLI para reiniciar o console
root@ccielab-fmc:~# /etc/rc.d/init.d/console reiniciar

Obs. Após reiniciar os processos, isso pode leva alguns minutos, não precisa se preocupar, não terá nenhuma indisponibilidade no ambiente, apenas a gerencia do FMC ficará indisponível até terminar o processo de reinicialização.

Cisco DMVPN – Parte-1

Neste post estarei apresentando uma introdução sobre o protocolo GRE, configurações com DMVPN e falando sobre as fases 1,2 e 3.

So, let’s talk first about it.

DMVPN

Estarei utilizando a topologia acima com as seguintes referencias, o HQ (Hub) se conecta à Internet e os dois Clientes (Spokes) de cada site possui seu próprio endereço IP público.

A configuração que estarei realizando será para esses sites se conectarem uns aos outros com seu próprio endereço IP privado utilizando túneis GRE.
O protocolo de transporte GRE oferece a possibilidade para criar conexões de túnel ponto a ponto e para isso é preciso informar o tunel source da interface e tunel destination dentro dentro da configuração de interface do GRE que será explicada mais a frente neste post.

GRE Notas importantes

  • GRE (Generic Routing Encapsulation) é um protocolo de encapsulamento que pode encapsular uma grande variedade de tipos de protocolos dentro de túneis, tais como, IP, IPX, Apple Talk e alguns outros que não lembro agora =).
  • O Túnel GRE pode ser usado para que dois roteadores na internet possam se comunicar com suas sub-rede privada.
  • O cabeçalho GRE cria pelo menos 24 bytes de overhead adicional para pacotes tunelados, é por isso que precisamos diminuir MTU para 1400 para libertar espaço para esses bytes adicionais.
  • O túnel GRE não irá criptografar ou proteger seus dados através dele, a menos que seja configurado o IPsec para esta finalidade.
  • O GRE pode ser usado para fornecer túnel ponto ou multiponto usando mGRE, falaremos dele mais adiante.

Tipo de endereço IP que será configurado no GRE ou mGRE:

  • Hub & Spokes IP Público: O endereço IP público também chamado de Outside address ou endereço IP NBMA.
  • Hub & Spokes IP Privado: O endereço IP privado (endereço IP do túnel) também é chamado de Enterprise address ou Inside address.

Neste exemplo: o endereço IP público do router R1 é 10.1.12.1 e o endereço IP público do router R2 10.1.12.2, será configurado uma interface de túnel para conectar ambos, a rede do túnel está definido com o endereço 180.180.180.0/24.

dmvpn-2

R1
interface Tunnel1
ip address 180.180.180.1 255.255.255.0
ip mtu 1400
tunnel source 10.1.12.1
tunnel destination 10.1.12.2
!
interface FastEthernet0/0
ip address 10.1.12.1 255.255.255.0

R2
interface Tunnel1
ip address 180.180.180.2 255.255.255.0
ip mtu 1400
tunnel source 10.1.12.2
tunnel destination 10.1.12.1
!
interface FastEthernet0/0
ip address 10.1.12.2 255.255.255.0

Agora espero que vc tenha feito a pergunta, e se eu tiver 100 filiais e quiserem se conectar ao HQ?…Lembra que esse é o nome do HUB, então precisarei configurar 100 tuneis GRE?!!! … Yes, you are right, no modo point-to-point é preciso configurar um túnel para cada Spoke, a gerencia e escalabilidade se torna um caos total para grandes ambientes!

Então o que fazer para facilitar o gerenciamento e a escalabilidade para um ambiente com a utilização de DMVPN?
Neste caso, podemos utilizar um outro protocolo chamado mGRE que fornecem túneis dinâmicos point-to-multipoint.
Ambos GRE & mGRE oferecem suporte para tráfego unicast, multicast e broadcast. Mas como nada é lindo e maravilhoso, em mGRE existe algumas considerações que precisam ser tratadas para evitar problemas, vamos falar mais tarde sobre isso quando chegar o momento de implementar o IGP com o DMVPN.

DMVPN
Quando utilizando o DMVPN ele permite criar uma única interface túnel mGRE e um único perfil para utilização de IPsec e aplicar na interface de túnel.

Componentes do DMVPN

  • CEF precisa estar sendo executado
  • Multipoint GRE
  • NHRP (Next Hop Resolution Protocol)
  • Protocolo de roteamento dinâmico ou rotas estáticas
  • Opcional – IPsec (GRE & mGRE não fornece proteção de criptográfica, é por isso que precisamos do IPsec para fazer isso por nós)

Para permitir que os Spokes conversem uns com os outros, precisamos fazer um mapeamento entre o endereço privado do túnel do HUB para o endereço IP público, é por isso que usamos o NHRP

Informações sobre NHRP:

  • NHRP fornece protocolos de resolução de endereços na camada 2 similar ao ARP ou ARP inverso do Frame Relay
  • NHRP é utilizado pelos Spokes para determinar o endereço NBMA do next hop router
  • Durante a configuração do NHRP é feito o mapeamento do endereço IP privado do túnel para o endereço IP público NBMA de forma estática ou dinâmica.
  • O NHRP é um protocolo cliente e servidor onde o hub atua como o servidor NHRP (NHS) e os Spokes são os clientes NHRP (NHC)
  • Cada Spoke registra seus endereços de túnel públicos e internos quando inicia e consulta o banco de dados NHRP para os endereços de outros Spokes
  • Ao adicionar um novo Spoke ao DMVPN não requer nenhuma configuração adicional no Hub. O Spoke é configurado apenas com as informações do Hub.

O DMVPN pode configurar em três maneiras fase 1, 2 e 3:

Fases do DMVPN 

Fase 1 – Hub & Spoke
– Nesta fase o mode de configuração mGRE é configurado no Hub, e o modo de GRE é configurado nos Spokes.
– Fluxo de tráfego de multicast ou unicast é somente entre o Hub e os Spokes apenas, e  NÃO entre Spokes to Spokes.
– Pode ser configurado de forma estática ou o NHC se registrará dinamicamente no NHS.
– Na Fase 1 os Spokes conversam entre eles apenas utilizando o Hub.

Fase 2 – Spoke-To-Spoke ou partial/full mesh
– Nesta fase o Hub e todos os Spokes serão configurados com mGRE.
– Na Fase 2 os Spokes podem conversar uns com os outros diretamente.

Fase 3
– É idêntico à fase 2 com uma grande diferença =D. usamos o comando ip nhrp redirect na configuração de tunel do Hub e ip nhrp shortcut na configuração de tunel dos Spokes.

A seguinte etapa acontece na fase 2 quando os Spokes precisam comunicar entre eles:
1- Spoke1 consulta seu cache NHRP local para o endereço IP do túnel do Spoke2 e se não encontra nenhuma entrada.
2-Envia uma consulta para o servidor NHRP (o roteador do hub DMVPN) para resolver o endereço interno (túnel) para um endereço IP externo do Spoke2.
3- O servidor NHRP, que mantém os endereços internos (túnel) e externo (físico) para roteadores do Spoke, envia uma resposta de NHRP para Spoke1, que informa que o IP do túnel interno do Spoke2 pode ser alcançado através do seu endereço IP (físico) externo.
4- Agora o Spoke1 recebe a resposta do servidor e adicionar essa entrada em seu cache local NHRP.

Configuração DMVPN – Esta configuração esta utilizando primeira topologia.
Nas duas fases 1 e 2, podemos usar o mapeamento estático ou o mapeamento dinâmico.

Exemplo de mapeamento estático da Fase 1:

Hub
interface tunnel 1
ip address 10.1.1.1 255.255.255.0
tunnel source 192.1.1.1
tunnel mode gre multipoint < Isso especifica a interface do túnel com um multiponto GRE, o que significa que estará atuando como interfaces únicas conectadas a múltiplos peers
ip nhrp network-id 111 < isso habilita o NHRP neste túnel, deve ser o mesmo no servidor NHRP e clientes NHRP.
ip nhrp map 10.1.1.2 192.1.2.2
ip nhrp map 10.1.1.3 192.1.3.3
ip nhrp map 10.1.1.4 192.1.4.4 < Estes comandos são para mapear os ips privados das interfaces de tunel dos Spokes para os endereços externos deles.

Nota: para suportar protocolos de roteamento dinâmico, habilite o suporte para tráfego de multicast com o comando ip nhrp map multicast dynamic sob a interface do túnel apenas no Hub. Isso permite que cada Spoke se registre como um receptor de tráfego multicast fazendo com que o Hub replica e encaminhe pacotes de multicast aos roteadores. Nos Spokes, configuramos ip nhrp map multicast 1.1.1.10 (onde 1.1.1.10 é o endereço IP público do hub), isso garante que o tráfego multicast seja enviado somente de Spokes para o Hub e não de Spoke para Spoke. Todo o tráfego multicast deve ser recebido pelo Hub, processado e, em seguida, as atualizações são enviadas para os Spokes

Na fase 1, não há necessidade do comando de multicast, porque a comunicação entre o Spoke com o Hub é Point-to-Point.

Spoke1
interface tunnel 1
ip address 10.1.1.2 255.255.255.0
tunnel source 192.1.2.2 < ou tunnel source f0/0
tunnel destination 192.1.1.1
ip nhrp netowrk-id 111
ip nhrp map 10.1.1.1 192.1.1.1

Spoke2
interface tunnel 1
ip address 10.1.1.3 255.255.255.0
tunnel source f0/0
tunnel destination 192.1.1.1
ip nhrp netowrk-id 111
ip nhrp map 10.1.1.1 192.1.1.1

Nota: para adicionar maior segurança podemos configurar autenticação entre o Hub e os Spokes: ip nhrp authentication C1$c0123, isso garante que as consultas indesejadas não sejam fornecidas com informações sobre a rede DMVPN.

Exemplo de mapeamento dinâmico da Fase 1:
Na configuração do Túnel do Hub não será adicionado os comandos “ip nhrp map

Hub
interface tunnel 1
ip add 10.1.1.1 255.255.255.0
tunnel source 192.1.1.1
tunnel mode gre multipoint
ip nhrp netowrk-id 111

Spoke1
interface tunnel 1
ip address 10.1.1.2 255.255.255.0
tunnel source 192.1.2.2
tunnel destination 192.1.1.1
ip nhrp netowrk-id 222
ip nhrp map 10.1.1.1 192.1.1.1 < mapeia o endereço NHS (10.1.1.1) para o endereço IP público (R1) do Hub (192.1.1.1).
ip nhrp nhs 10.1.1.1 < envie solicitação de registro para o Hub, informa a este Spoke quem é Next Hop Server (NHS).

Spoke2
interface tunnel 1
ip address 10.1.1.3 255.255.255.0
tunnel source f0/0
tunnel destination 192.1.1.1
ip nhrp netowrk-id 333
ip nhrp map 10.1.1.1 192.1.1.1
ip nhrp nhs 10.1.1.1

Comandos para verificação e Tshoot DMVPN

sh ip nhrp
sh ip nhrp detail

show ip nhrp nhs: Exibe as informações do servidor NHRP next-hop e pode ser usado  para mostrar informações de mapeamento NHRP para um dispositivo.

debug nhrp packet
sh dmvpn: Verifica os spokes registrados no Hub.