VPN Site-to-Site com overlapping de endereços

Neste post vamos falar sobre algo que pode acontecer com qualquer consultor de redes e segurança desde o nível básico a nível de arquiteto, quando configuramos o endereçamento de uma rede interna escolhemos quais serão os ranges de escala aleatória da RFC1918 para endereçamento de nossos dispositivos no ambiente.
Mas podemos nos deparar com alguns cenários onde não temos o controle sobre qual range de endereço foi definido para endereçamento dos dispositivos, então logo que estamos falando sobre VPNs entre dois site, vem o risco de sobreposição de endereços, quando isso acontece, a seguinte pergunta ocorre, eae? ferrou, como vamos resolver este problema? podemos trocar o endereço da nossa LAN? sim podemos, porém é somente a rede onde se encontra todos os servidores do nosso ambiente como AD, Banco de Dados, DNS, etc, melhor não né? ou então pode pedir para o Sysadmin do site remoto trocar o endereço dele, vamos jogar a bomba para ele né, absurdamente insano pensarmos isto, correto? Claro Sim!

Então, como podemos corrigir a sobreposição? Aham! Com NAT, mas é claro! =D

Neste post vou mostrar como usar o conceito de “Twice NAT” ou traduzindo ao pé da letra “duas vezes NAT”, com esse tipo de NAT podemos trabalhar de boa quando ocorrer sobreposição de endereços entre duas redes. Isso aí, let’s go!

Considerações antes de começarmos:

  • Conforme outros posts, não vou abordar as configurações iniciais de Firewall, ACLs, etc, estou partindo do princípios que seu ambiente já esteja configurado.
  • Antes de prosseguir com esta configuração, certifique-se que os firewalls estejam com as configurações de endereços IPs e tenham conectividade básica com internet e rotas para a rede (192.168.1.0/24) caso não sejam diretamente conectadas.

Topologia VPN Site-to-Sitenat-twice

Observem que na topologia acima, as redes LAN1 e LAN2 está definida com os mesmos endereços, 192.168.1.0/24, então em situações como esta nada melhor que nosso bom e velho NAT entrar em ação.

Para que as duas redes que estão com sobreposição de endereços se comuniquem, temos que configurar o NAT em ASA1, será definido duas sub-redes que não estejam em utilização para ambos os lados do ambiente.

Rede LAN1 192.168.1.0/24 será visto como 192.168.101.0/24 do ponto de vista da rede LAN2.
Rede LAN2 192.168.1.0/24 será visto como 192.168.201.0/24 do ponto de vista da rede LAN1.

Muito legal né! =D

A função aqui é garantir que um host 192.168.1.1 na rede LAN1 seu endereço seja traduzido para 192.168.101.1 do ponto de vista da LAN2.

Configuração de VPN
Não vou entrar em detalhes durante esta etapa porque já existe um post pronto neste link.

Configuração Fase 1
ASA-1:
ASA-1(config)# crypto ikev1 policy 10
ASA-1(config-ikev1-policy)# authentication pre-share
ASA-1(config-ikev1-policy)# encryption aes
ASA-1(config-ikev1-policy)# hash sha
ASA-1(config-ikev1-policy)# group 2

ASA-1(config)# crypto ikev1 enable OUTSIDE

ASA-1(config)# tunnel-group 101.0.0.1 type ipsec-l2l
ASA-1(config)# tunnel-group 101.0.0.1 ipsec-attributes
ASA-1(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

ASA 2:
ASA-2(config)# crypto ikev1 policy 10
ASA-2(config-ikev1-policy)# authentication pre-share
ASA-2(config-ikev1-policy)# encryption aes
ASA-2(config-ikev1-policy)# hash sha
ASA-2(config-ikev1-policy)# group 2

ASA-2(config)# crypto ikev1 enable OUTSIDE

ASA-2(config)# tunnel-group 201.0.0.1 type ipsec-l2l
ASA-2(config)# tunnel-group 201.0.0.1 ipsec-attributes
ASA-2(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

Fase 2 do IPsec
ASA 1:
ASA-1(config)# access-list LAN1-to-LAN2 extended permit ip 192.168.101.0 255.255.255.0 192.168.1.0 255.255.255.0

ASA-1(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-1(config)# crypto map ASA1 10 match address LAN1-to-LAN2
ASA-1(config)# crypto map ASA1 10 set peer 101.0.0.1
ASA-1(config)# crypto map ASA1 10 set ikev1 transform-set ESP-TS
ASA-1(config)# crypto map ASA1 interface OUTSIDE

ASA 2:
ASA-1(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.1.0 255.255.255.0 192.168.101.0 255.255.255.0

ASA-2(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-2(config)# crypto map ASA2 10 match address LAN2-to-LAN1
ASA-2(config)# crypto map ASA2 10 set peer 201.0.0.1
ASA-2(config)# crypto map ASA2 10 set ikev1 transform-set ESP-TS
ASA-2(config)# crypto map ASA2 interface OUTSIDE

ASA 2:
ASA-2(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.1.0 255.255.255.0
192.168.101.0 255.255.255.0

Configuração de Objetos e NAT
Um ponto importante é que toda a mágica do Twice NAT acontece apenas no ASA1, durante a configuração pode parecer um pouco confuso, I know, mas vamos tentar entender a lógica do negocio.

No ASA1 os seguintes objetos serão configurados.

ASA 1:
ASA-1(config)# object network LOCAL-LAN1
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0

É como a rede local será vista a partir da rede remota:
ASA-1(config)# object network LOCAL-LAN1-NAT
ASA-1(config-network-object)# subnet 192.168.101.0 255.255.255.0

ASA-1(config)# object network REMOTE-LAN2
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-1(config)# object network REMOTE-LAN2-NAT
ASA-1(config-network-object)# subnet 192.168.201.0 255.255.255.0

Talvez você tenha pensado ué, LOCAL-LAN1 e LOCAL-LAN2 aponta para a mesma rede? Sim, então poderíamos utilizar apenas o objeto LOCAL-LAN1? sim poderíamos, porém, para a logica da estrutura que será construída fica mais fácil utilizar este modelo de configuração.

No ASA2 os seguintes objetos serão configurados.
ASA 2:
ASA-2(config)# object network LOCAL-LAN1
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0

É como a rede local será vista a partir da rede remota:
ASA-2(config)# object network LOCAL-LAN1-NAT
ASA-2(config-network-object)# subnet 192.168.201.0 255.255.255.0

ASA-2(config)# object network REMOTE-LAN2
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-2(config)# object network REMOTE-LAN2-NAT
ASA-2(config-network-object)# subnet 192.168.101.0 255.255.255.0

Configuração de NAT ASA-1 & ASA-2

ASA1:
nat (INSIDE,OUTSIDE) source static LOCAL-LAN1 LOCAL-LAN1-NAT destination static REMOTE-LAN2-NAT REMOTE-LAN2

Let’s go tentar entender toda essa bagaça.

A primeira parte do comando source traduz a rede local LOCAL-LAN1 (192.168.1.0/24) para LOCAL-LAN1-NAT (192.168.101.0/24) quando ela precisar falar com  a rede REMOTE-LAN2-NAT (192.168.201.0/24)

A segunda parte do comando destination traduz a rede remota REMOTE-LAN2-NAT (192.168.201.0/24) para REMOTE-LAN2 (192.168.1.0/24).

ASA2:
nat (INSIDE,OUTSIDE) source static LOCAL-LAN1 LOCAL-LAN1 destination static REMOTE-LAN2-NAT REMOTE-LAN2-NAT

Para a configuração de NAT em ASA2, não temos nenhuma novidade, precisamos em destination apenas apontar para o objeto REMOTE-LAN2-NAT (192.168.101.0/24).

 

Topologia Final VPN Site-to-Site com Twice NAT
fw-internet

 

That’s it for now.

 

 

Upgrade NSX Manager 6.2.2/3 para 6.2.4

Após um bom tempo apanhando em busca de materiais/informações na internet com procedimentos sobre como realizar o upgrade de NSX, resolvi criar este passo a passo com todas as informações que utilizei durante minhas atividades.

Antes de começar é extremamente recomendado que seja feita a leitura completa do Release Notes referente a versão que está sendo atualizada.

Para o upgrade de versão do NSX, devemos seguir os seguintes passos para atualização da Manager e os demais componentes.

1. Appliance do NSX Manager
2. Cluster de Controllers
3. Hosts (VIBs)
4. NSX Edge/DLR
5. Endpoint/Data Security

nsx-up-1

Considerações antes da atualização:

  • Não deixe de ler e prestar atenção no Release Notes para versão do NSX.
  • Precisamos fazer o download do bundle de atualização do NSX e verificação do MD5.
  • Faça backup da Manager do NSX, é uma boa opção também realizar um snapshot da VM do NSX antes da atualização, faça um backup da configuração do Web Client do Vsphere.

Passo1:
Primeiramente precisamos acessar o site da VMware e baixar o bundle de upgrade do NSX.

bundle

Passo2:
Conectar ao NSX Manager e siga para a página de atualização, selecionar o botão Upgrade.

00

E informe a localização do arquivo “VMware-NSXManager-
upgrade-bundle-6.2.4-4292526.tar.gz”.

nsx1

Agora isso vai demorar um bom tempo até terminar o upload é super recomendado que você vá até a máquina de café e se sirva. =)

01-upload-bundle

Após terminar o upload será apresentado a seguinte página responda as duas opções e clique em Upgrade para continuar.

03-upload-bundle

Passo3:
Após terminar o upgrade podemos verificar que a manager foi atualizada corretamente e se encontra na versão 6.2.4, precisamos checar se todos os serviços estão rodando, clique em “View Summary”.

nsx8

Tudo se encontra em ótimas condições, podemos confirmar isto analisando os campos “Common Components e NSX Management Components”. NEXT =)

nsx9

Passo3:
Após atualização da Manager, precisamos atualizar o Cluster de Controllers. Entre no Web Client do vCenter e vá até Networking & Security > Installation. Na aba “Management” será apresentada uma informação de atualização disponível para os Controllers “Upgrade Available”. Clique sobre ela para iniciar o processo de atualização.

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir.

upgrade8

Isso leva algum tempo para terminar, minha recomendação é que você retorne a máquina de café e se sirva novamente. =)

upgrade11

Obs. Os controllers serão reiniciados um após o outro depois do upgrade.

upgrade13

Posso4:
Estamos quase chegando ao final do nosso objetivo, agora é a parte mais legal na minha opinião, atualização das VIBs dos Hosts!
Este processo é obrigatório que os Hosts que fazem parte do cluster ESXi sejam reiniciados após atualização de cada um deles, então vamos ao que interessa.
Para começarmos nosso upgrade, vamos no seguinte caminho Networking & Security > Installation > Host Preparation, será a apresentando uma informação de “upgrade available”, ao clicar nela serão instaladas as VIBs para os respectivos Hosts daquele Cluster.

untitled

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir.

nsx17

Em alguns casos na aba Installation Status pode acontecer de apresentar a seguinte mensagem ‘Not Ready‘, clique sobre a mensagem de erro em vermelho e após clique em Resolve all.

nsx19

Passo5:
Após terminar a instalação das VIBs em todos os hosts precisamos reiniciar cada um deles, acabei não fazendo o print das imagens para esta etapa “I’m sorry”, mas basicamente o processo é o seguinte, para cada host que será reiniciado precisamos mudar ele para modo de manutenção e esperar que as VMs sejam migradas para o outro Host do cluster e então podemos reiniciar em segurança, simples e fácil assim. =D

No final tudo deve ficar como a imagem abaixo, pronto, as VIBs foram instaladas corretamente aos Hosts do Cluster, NEXT.

nsx21

Passo6:
Para a última etapa será feito o upgrade dos Edges e DLRs, vamos em Networking & Security > NSX Edges, observe que eles estão na versão 6.2.3.

nsx25

Clique com o botão direito em cada dispositivo que será feito o upgrade e em
seguida, selecione “Upgrade Version”.

nsx30

Uma janela solicitando a confirmação de upgrade será apresentada, apenas clique em Yes para prosseguir com o upgrade.

nsx23

Após a atualização podemos verificar que o status dos Edges e DLRs estão com a versão de imagem correta 6.2.4.

nsx32

 

Espero que este post seja útil para você, obrigado!

Configurando VPN IPsec entre ASA

A algum tempo atrás, eu tinha em mente que VPN era apenas e unicamente aquela coisa de um aplicativo ou uma configuração que é realizada somente no Windows para acessar a rede onde trabalhamos, é impressionante como nossos pensamentos vão mudando conforme vamos entendendo a real funcionalidade do negocio, e qual sua utilidade, trabalhando hoje como consultor em Redes e Segurança, posso dizer que VPN não é somente aquela configuração básica feita para acessar o ambiente onde trabalhamos, mas sim um protocolo incrível e fantástico, praticamente utilizada no mundo inteiro, hoje eu posso entender e apontar as várias vantagens para utilização delas, vamos conversar aqui sobre a VPN Site-to-Site utilizada para conectar e permitir que duas ou mais redes remotas possam conversarem como se estivessem na mesma rede local, também utilizado para redundância quando o meio principal é MPLS por exemplo, entre outros.
Estou escrevendo este post para mostrar como é feito a configuração de uma VPN Site-to-Site entre 2x ASA utilizando IPsec com IKEv1.

Tá, falei de VPN e logo em seguida comentei sobre IPSec, IKEv1 e mais um monte de nomes, vamos por partes, mas afinal o que é isso, o que é IPSec?
Vamos agora falar sobre alguma teoria por trás do IPsec, a fim de ter uma base de conhecimento para a compreensão referente a configuração que vamos iniciar.

O protocolo IPsec trabalha especificamente na camada de rede do modelo OSI, a função dele basicamente consiste na criptografia e autenticação dos pacotes IPs entre outros equipamentos participantes conhecidos como(peers), a conexão pode ser estabelecida com equipamento do tipo de Roteadores Cisco, Firewalls Cisco, softwares de VPN, etc. Como o IPsec é um padrão aberto IETF, outros fornecedores de firewall, roteadores e sistemas operacionais também suportam ele, então é ideal para construir conexões VPNs entre dispositivos de diferentes fornecedores.

Os seguintes protocolos serão usados em nossa configuração, então achei interessante dar uma pincelada basica referente ao que se trata cada um deles.

  • ESP (Encapsulation Security Payload): Fornece integridade de dados, autenticação e serviços de confidencialidade. O ESP é usado para criptografar o payload dos pacotes IPs.
  • AH (Authentication Header): Fornece integridade de dados, autenticação, não fornece serviços de criptografia, mas sim atua como uma “assinatura digital” para os pacotes para garantir que a adulteração de dados não tenha ocorrido.
  • Internet Key Exchange (IKE): Este é o mecanismo usado pelos dispositivos para iniciar a troca segura de chaves de criptografia, autenticação de peers IPsec e negociação de parâmetros de segurança IPsec. No firewall ASA, conhecemos ele como ISAKMP, vamos ver na pratica como é a configuração.
  • DES, 3DES, AES: Todos eles são algoritmos de criptografia suportados pelo Cisco ASA Firewall.
  • Diffie-Hellman Group (DH): Este é um protocolo de criptografia de chave pública usado pela IKE para estabelecer a sessão de chaves.
  • MD5, SHA-1: Ambos são algoritmos de hash usados para autenticação de dados para os pacotes. O algoritmo SHA é mais forte do que MD5.
  • Security Association (SA): Quando se fala em uma conexão IPsec é muito comum fazer referencia para uma SA, que nada mais é uma conexão entre dois peers IPsec. Cada peer IPsec mantém um banco de dados SA em sua memória contendo parâmetros SA, basicamente é endereço do peer remoto, protocolos de segurança e parâmetros de segurança.

Topologia Site-to-Site IPSEC IKEv1

drawing1

O nosso objetivo aqui é conectar as duas redes LAN distantes através da Internet e utilizando o protocolo IPsec estaremos aplicando um nível maior de segurança dizendo que qualquer pacote que trafegar dentro do tunel será criptografado.
As redes locais também chamadas de uma LAN eu digo que +|- 90 – 95% das vezes elas estão utilizando endereçamento privados RCF1918 como mostrado em nosso diagrama acima e fazendo NAT no Firewall ou Roteador para acesso a internet. Então sem a conectividade de VPN, as duas redes LAN acima (LAN1 e LAN2) seriam incapazes de se comunicarem entre elas. Agora que acontece a mágica, configurando uma VPN Site-to-Site com IPsec entre os dois firewalls ASA, podemos estabelecer um túnel seguro pela Internet e passar nosso tráfego dentro deste túnel. O resultado é que os hosts na rede 192.168.1.0/24 agora podem acessar diretamente hosts na rede 192.168.2.0/24 e vice-versa como se estivessem localizados na mesma LAN. O túnel IPsec é estabelecido entre os endereços IP públicos dos firewalls (201.0.0.1 e 101.0.0.1).

Podemos dizer que basicamente existem cinco etapas na operação do IPsec, descreveremos os comandos de configurações necessários para cada etapa a fim de configurar a VPN. Para todos os exemplos de configurações estamos utilizando como base o diagrama de rede acima. Esta configuração é para o IPsec IKEv1 . Em um outro post veremos também como configurar VPNs IPsec com IKEv2.

Obs. Não estarei abordando neste post a configuração inicial do ASA bem como acesso a Internet, NAT, ACLs, etc, isto será assunto para outros posts, vamos lá configurar está bagaça.

Passo1: Configurar tráfego interessante, ou seja, qual rede que vamos tunelar pela VPN.
Usando uma ACL podemos identificar qual fluxo de tráfego deve ser criptografado. Em nosso diagrama acima, queremos que todo o fluxo de tráfego entre as redes 192.168.1.0/24 e 192.168.2.0/24 sejam criptografados.

ASA 1:
ASA-1(config)# access-list LAN1-to-LAN2 extended permit ip 192.168.1.0 255.255.255.0
192.168.2.0 255.255.255.0

ASA 2:
ASA-2(config)# access-list LAN2-to-LAN1 extended permit ip 192.168.2.0 255.255.255.0
192.168.1.0 255.255.255.0

Atenção.  Reparem que a lista de acesso é espelho entre os Firewalls que participam da VPN Site-to-Site,  é muito comum encontramos problemas com ACLs que classificam as redes por exemplo com a mascara diferente, e acreditam em mim, é complicado pra caramba identificar o problema, então, quando se deparar com instabilidades na Fase 1 com o túnel VPN subindo e caindo de uma olhadinha nas ACLs em ambos os firewalls. =)

Exclusão NAT para tráfego VPN
Uma questão importante a considerar é o caso de usar NAT no firewall para acesso à Internet.
Como o IPsec não funciona com NAT, precisamos excluir o tráfego a ser criptografado da operação NAT, segue exemplos de como configurar para versões acima da 8.3).

ASA 1:
ASA-1(config)# object network VPN-LOCAL
ASA-1(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-1(config-network-object)# exit
ASA-1(config)# object network LAN-REMOTO
ASA-1(config-network-object)# subnet 192.168.2.0 255.255.255.0
ASA-1(config-network-object)# exit
ASA-1(config)# nat (INSIDE,OUTSIDE) source static VPN-LOCAL VPN-LOCAL destination static LAN-REMOTO LAN-REMOTO

ASA 2:
ASA-2(config)# object network VPN-LOCAL
ASA-2(config-network-object)# subnet 192.168.2.0 255.255.255.0
ASA-2(config-network-object)# exit
ASA-2(config)# object network LAN-REMOTO
ASA-2(config-network-object)# subnet 192.168.1.0 255.255.255.0
ASA-2(config-network-object)# exit
ASA-2(config)# nat (INSIDE,OUTSIDE) source static VPN-LOCAL VPN-LOCAL destination static LAN-REMOTO LAN-REMOTO

Passo2: Configuração Fase 1 IKEv1 ou ISAKMP como preferir chamar =)
A Fase 1 da operação IPsec é usada para estabelecer o primeiro túnel de comunicação para transmissão de dados. Na fase 1, os peers de VPN trocam chaves secretas compartilhadas, autenticam-se, negociam políticas de segurança de IKE, etc. Nesta Fase nós configuramos uma política de ikev1 que DEVE combinar a política configurada no outro peer. Esta política ikev1 diz aos outros peers quais parâmetros de segurança devem ser usados na VPN.

ASA 1:
ASA-1(config)# crypto ikev1 policy 10
ASA-1(config-ikev1-policy)# authentication pre-share
ASA-1(config-ikev1-policy)# encryption aes
ASA-1(config-ikev1-policy)# hash sha
ASA-1(config-ikev1-policy)# group 2

ASA-1(config)# crypto ikev1 enable OUTSIDE

ASA-1(config)# tunnel-group 101.0.0.1 type ipsec-l2l * IP do peer Remoto
ASA-1(config)# tunnel-group 101.0.0.1 ipsec-attributes
ASA-1(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

ASA 2:
ASA-2(config)# crypto ikev1 policy 10
ASA-2(config-ikev1-policy)# authentication pre-share
ASA-2(config-ikev1-policy)# encryption aes
ASA-2(config-ikev1-policy)# hash sha
ASA-2(config-ikev1-policy)# group 2

ASA-2(config)# crypto ikev1 enable OUTSIDE

ASA-2(config)# tunnel-group 201.0.0.1 type ipsec-l2l # IP do peer Remoto
ASA-2(config)# tunnel-group 201.0.0.1 ipsec-attributes
ASA-2(config-tunnel-ipsec)# ikev1 pre-shared-key @Cisco@123

Passo3: Após estabelecer o túnel na Fase 1, a próxima etapa na configuração da VPN é negociar os parâmetros de segurança IPsec que serão usados para proteger os dados e as mensagens dentro do túnel, isto é o que acontece durante a Fase 2 do IPSEc.

ASA 1:
ASA-1(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-1(config)# crypto map ASA1 10 match address LAN1-to-LAN2
ASA-1(config)# crypto map ASA1 10 set peer 101.0.0.1
ASA-1(config)# crypto map ASA1 10 set ikev1 transform-set ESP-TS
ASA-1(config)# crypto map ASA1 interface OUTSIDE

ASA 2:
ASA-2(config)# crypto ipsec ikev1 transform-set ESP-TS esp-aes-192 esp-sha-hmac
ASA-2(config)# crypto map ASA2 10 match address LAN2-to-LAN1
ASA-2(config)# crypto map ASA2 10 set peer 201.0.0.1
ASA-2(config)# crypto map ASA2 10 set ikev1 transform-set ESP-TS
ASA-2(config)# crypto map ASA2 interface OUTSIDE

Passo4: Verificação se o túnel está UP
Com os três passos acima concluímos a configuração de uma VPN IPsec Site-to-Site. Agora, podemos iniciar a verificação se tudo está funcionando conforme esperamos e se os dados estão realmente sendo criptografados pelos firewalls. Vamos utilizar dois comandos importantes que o ajudarão a verificar se o túnel está estabelecido e se os dados sendo bidireccionalmente criptografados.

Verificar se o túnel está estabelecido
O comando show crypto isakmp sa verifica se a Security Association (SA) está estabelecida, o que significa que o túnel está em funcionamento. Vamos ver um exemplo de saída deste comando abaixo:

ASA1# show crypto isakmp sa
IKEv1 SAs:

Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1

1 IKE Peer: 101.0.0.1
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
There are no IKEv2 SAs

O ponto importante aqui é observar que o State : MM_ACTIVE. Isso confirma que a Fase 1 do IPsec foi estabelecido com sucesso.

Verificar se os dados estão criptografados bidirecionalmente
O comando show crypto ipsec sa verifica se os dados estão sendo criptografados e descriptografados.

ASA1# show crypto ipsec sa
interface: OUTSIDE
Crypto map tag: ASA1, seq num: 10, local addr: 101.0.0.1
access-list LAN1-to-LAN2 permit ip 192.168.1.0 255.255.255.0 192.168.2.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
current_peer: 201.0.0.1

#pkts encaps: 3150, #pkts encrypt: 2050, #pkts digest: 2050
#pkts decaps: 2108, #pkts decrypt: 3149, #pkts verify: 2108
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2050, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 101.0.0.1, remote crypto endpt.: 201.0.0.1
—Output Omitted—

A saída #pkts encrypt:3150 e #pkts decrypt:3149 mostram que temos criptografia de dados bidirecional.

 

 

Isso é tudo por hoje, espero que possa ajudar alguém!

Procedimento para Recover de Password FW ASA

Se por algum motivo você ficou bloqueado para o lado de fora do ASA ou simplesmente estiver precisando iniciar o procedimento para fazer Recovery de Password, os seguintes passos pode ser de grande ajudar para resolver este problema.

Passo 1:
Conecte um um cabo de console ao ASA, desligue e ligue o equipamento.

Passo 2:
Pressione continuamente a tecla “ESC” do teclado até o dispositivo entrar no modo ROMMON. O seguinte modo será exibido:
Rommon #1>

Passo 3:
Será preciso mudar o “Config Register”, está configuração controla como a será lida a startup-config.

Passo 4:
Agora é preciso alterar o valor do confreg para 0x41, o que estamos dizendo aqui é para o Firewall ignorar a configuração da startup-config durante a inicialização. Após definir o novo confreg, reinicie o equipamento.
Rommon #2> confreg 0x41
Rommon #3> boot

Passo 5:
Nosso FW ASA irá ignorar a configuração de inicialização da startup-config, ao digitar “enable” você vai perceber que nenhuma senha foi solicitada.
Ciscoasa> enable
Senha: ciscoasa#

Passo 6:
Agora precisamos copiar o arquivo de configuração da startup-config para a running-config.
ciscoasa# copy startup-config running-config
Deixe o nome do arquivo para o destino conforme sugerido [running-config]?

Passo 7:
Agora configure uma a nova senha e também precisamos voltar a configuração do Config Register para seu valor original (0x01).
ciscoasa# configure terminal
ciscoasa(config)# enable password X@cisco@123
ciscoasa(config)# config-register 0x01
ciscoasa(config)# write mem

Passo 8:
Recomendo que seja feito outro reload no Firewall para validar as configurações. Após Reiniciar você deve ser capaz de entrar com a nova senha.
ciscoasa(config)# reload