- Introdução
- Passo 1 - Teste de Ping
- Passo 2 - Configuração VLANs - VPN
- Passo 3 - Validação VLANs participantes na VPN
- Passo 4 - Tabela de Roteamento
- Passo 5 - Regras de Firewall
- Passo 6 - Análise com Wireshark
- Passo 7 - Validando os logs do Cisco Meraki
- Passo 8 - Análise com Terceiros
- Conclusão
Introdução
Este artigo objetiva demonstrar como realizar o troubleshooting e encontrar a causa raiz para o não funcionamento da comunicação entre VLANs no site-to-site VPN no Cisco Meraki. Este problema foi encontrado em uma situação de dia a dia ao tentar estabelecer comunicação entre subnets no site-to-site VPN no Cisco Meraki.
É recomendável, não obrigatório, que o leitor tenha entendimento de:
- Conhecimento de configuração de VLANs e Subnets no Cisco Meraki.
- Conhecimento de rotas no Cisco Meraki.
- Conhecimento do funcionamento de VPNs no Cisco Meraki.
- Conhecimento base de captura com o Wireshark
Recursos do lab
- MX64 - HQ
- MX64Q - Branch
- Firmware: 18.107.2 para ambos MX
Na topologia demonstrada abaixo existem duas redes ou sites, como acharem melhor dizer, HQ e Branch1, com duas VLANs/subnets em cada localidade e essas devem estabelecer comunicação entre si através da auto VPN do Cisco Meraki.
O HQ é o hub e o Branch1 o site spoke.
Mesmo com o site-to-site VPN configurada, a comunicação entre essas VLANs não é estabelecida.
Observe a VPN mostra estabelecida, e o status de Connectivity como Down.
Sendo assim, seguem alguns passos a serem seguidos na tentativa de encontrar a causa raiz do problema.
Nota: Apesar de alguns passos demonstrados a seguir fazerem parte da configuração da VPN site-to-site, o foco é o troubleshooting e não a configuração da VPN em si.
Passo 1 - Teste de Ping
Usualmente como primeiro teste de conectividade é o ping. Sendo assim, não é preciso realizar o teste entre dispositivos finais na rede, este pode ser realizado diretamente no dashboard do Meraki.
Vá em Security & SD-WAN > Appliance Status > Tools.
Na tentativa do ping entre as VLANs para os IPs de ambos MX, há perda de pacote.
Passo 2 - Configuração VLANs - VPN
Visto que a comunicação não é estabelecida, verifique se as VLANs de interesse estão como Enabled na configuração de Site-to-site VPN. Vá em Security & SD-WAN > Configure > Site-to-site VPN, e em VPN settings / Local networks verifique a configuração.
- HQ: VLANs 50 e 70
- Branch1: VLANs 20 e 100
Passo 3 - Validação VLANs participantes na VPN
Valide se as VLANs/subnets de interesse estão presentes em VPN participants. Vá em Security & SD-WAN > Monitor > VPN Status. Tanto a VLAN 20 e 100 para Branch, e 50 e 70 para HQ estão presentes na tabela.
HQ - VPN Participants
Branch - VPN Participants
Passo 4 - Tabela de Roteamento
Consulte a tabela de roteamento para assegurar que cada o Next-hop de cada VLAN. Vá em Security & SD-WAN > Monitor > Route Table.
Para o lado de HQ, O Branch está como Next-Hop para as VLANs 20 e 100.
Para o lado de Branch, acontece o oposto, a HQ está como Next-Hop para as VLANs 50 e 70.
Branch - Routing Table
Passo 5 - Regras de Firewall
Um passo também importante, é confirmar se existe alguma configuração de regra de Firewall para ambos os sites, que possa estar impactando este tráfego.
Vá em SD-WAN > Monitor > Configure > Firewall.
Tanto HQ como Branch, não possuem regras inbound nem outbound.
Um observação importante, é que o tráfego de Internet para serviços como HTTPS, DNS, entre outros, estavam funcionais para ambos os sites durante a fase de troubleshooting.
Passo 6 - Análise com Wireshark
Para se aprofundar no troubleshooting, uma validação como a captura de pacotes e análise no Wireshark é de grande valor, e em determinados momento ajuda a detecção do problema.
Vá em Network-wide > Monitor > Packet capture, selecione o Packet Capture para security appliance e a Interface para Site-to-Site VPN. Defina o tempo para a captura.
É válido que a captura seja executada simultaneamente para ambos os lados, a fim de verificar se algum tipo de tráfego é gerado por algum dos sites dentro da VPN.
Nota: Para essa captura foi realizado um teste de ping de HQ para Branch e vice-versa.
Nas imagens abaixo, ambos os lados enviam o ICMP, porém não recebem a resposta. Isso acontece para todos os pacotes.
Passo 7 - Validando os logs do Cisco Meraki
Vá em Network-wide > Monitor > Event log, e em Event type include selecione, All Meraki VPN, e clique em Search.
Muitos logs de conexão e desconexão acontecia para ambos os lados. Abaixo os logs do Branch.
Com a validação dos logs de conexão e também observando o funcionamento do uplink de ambos os sites, note que muitas ocilações acontecem no Uplink para do site Branch, porém, como mencionado anteriormente, o tráfego de Internet continuava funcionando para os usuários do Branch, e o tráfego de VPN impactado.
- Uplink HQ
- Uplink Branch
Passo 8 - Análise com Terceiros
Dessa forma, é seguir e investigar com o provedor do link de Internet quais anomalias estão ocorrendo no link de Internet.
É também importante envolver o TAC/suporte do fabricante para que faça uma análise se existe algum bug no produto.
Neste caso, ambos foram envolvidos, provedor do link de Internet do Branch como o TAC da Meraki.
- O TAC não detectou nenhum tipo de problema em ambos os equipamentos.
- A resposta do provedor local é que estavam com manutenção na rede, por isso a estabilidade. Não foram informados mais detalhes se existia alguma problema de bloqueio de algum protocol ou porta dentro da rede.
O serviço de VPN se reestabeleceu e o tráfego na VPN voltou a normalidade.
As imagens acima demonstram o funcionamento da VPN e a conexão estabelecida. Note que na última captura, existe tráfego de controle do protocolo BGP, algo que não existia anteriormente. O BGP é utilizado no backgroud para o roteamento de tráfego na Auto VPN do Meraki.
Conclusão
A causa raiz do problema não foi detectada. Como conclusão técnica do comportamento do link de Internet no Branch 1, supõe-se que existia algum tipo de bloqueio para porta e protocolos dentro da rede do provedor que estava afetando o funcionamento da VPN site-to-site.
Em muitos casos, provedores de Internet bloqueiam portas e serviços, com o intuito de mitigar ataques na rede, e isso acaba influenciando na experiência do usuário como também impactando o serviço dos clientes.
Outro fator, de não encontrar a causa raiz com o provedor local, é que tratamos aqui de um link de Internet caseiro, sem SLA para o serviço. Caso fosse para um link corporativo, que existe um contrato com um SLA determinado, a possibilidade de chegar ao diagnóstico conclusivo, seria mais fácil..
Espero que tenham aproveitado a leitura. Compartilhe!
Obrigado!
Jonas Resende
