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

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.