Você já passou por essa situação? Configura uma VPN IPsec Site-to-Site entre um Mikrotik e um outro Vendor, o túnel sobe, a Fase 1 fecha, todas as Fases 2 fecham... mas o tráfego se comporta de forma estranha.
Se você tenta acessar a rede A, ela funciona. Mas assim que alguém acessa a rede B, a rede A cai. Parece que o túnel "escolhe" apenas uma sub-rede para funcionar por vez, mesmo que todas apareçam como "Established" no Mikrotik.
Recentemente peguei um cenário exatamente assim em um Mikrotik RB3011 (RouterOS v7.20.2) e, neste tutorial, vou mostrar como resolver esse conflito de Fase 2.
Tínhamos uma VPN fechada onde o Mikrotik precisava comunicar 3 redes locais distintas com o lado do cliente (Fortigate):
Rede 1: 10.0.10.0/24
Rede 2: 172.16.0.0/24
Rede 3: 192.168.0.0/24
O Sintoma: Ao trafegar dados na rede 10.0..., a 172.16... parava de responder. Se forçássemos o tráfego na 172.20..., a primeira caía e assim por diante. Era um "cabo de guerra" digital.
O problema está na forma como o Mikrotik gerencia as Associações de Segurança (SAs) na Fase 2.
Por padrão, as políticas IPsec no Mikrotik vêm configuradas com o nível (Level) definido como require. Quando você tem múltiplas políticas apontando para o mesmo Peer, o Mikrotik pode tentar agrupar tudo ou se confundir, gerando um conflito de identidade.
Basicamente, ele cria um túnel e acha que todo o tráfego deve passar por aquele identificador único, causando o sombreamento (shadowing) das outras sub-redes. O Fortigate, que costuma aceitar múltiplos seletores, fica esperando conexões distintas que o Mikrotik não está entregando separadamente.
Para resolver, precisamos dizer ao Mikrotik: "Crie um túnel exclusivo e independente para cada par de redes". Fazemos isso alterando o Level da política para unique.
O foco aqui é o Winbox e resolver a dor de cabeça de ter a VPN conectada, mas as redes caindo uma por cima da outra.
Siga este procedimento para cada uma das sub-redes configuradas na sua VPN:
1. Acesse as Políticas IPsec
Abra seu Winbox, vá no menu lateral IP e depois em IPsec. Clique na aba Policies.
Aqui você verá suas regras. Note que, no seu cenário, você deve ter 3 linhas separadas (uma para cada rede local apontando para a rede remota).
2. Edite a Política
Dê um duplo clique na primeira regra de política (ex: a da rede 10.0.10.0/24).
Vá até a aba Action.
3. O "Pulo do Gato"
Nesta aba, procure pelo campo Level. Ele provavelmente estará marcado como require.
Mude o Level para unique.
Garanta que a caixinha Tunnel esteja marcada.
Dê OK.
🔴 Importante: Você precisa repetir esse passo em TODAS as políticas (Phase 2) que pertencem a essa mesma VPN. No nosso exemplo, você fará isso 3 vezes (uma para cada rede).
4. Limpando a Conexão
Depois de alterar tudo para unique, as conexões podem não se corrigir sozinhas imediatamente.
Vá na aba Active Peers.
Derrube a conexão com o Peer que você está fechando essa VPN(clique no - vermelho ou botão de Kill).
Quando ela reconectar, o Mikrotik negociará SAs individuais para cada sub-rede.
🔴 🔴 🔴 ATENÇÃO: CUIDADO DOBRADO PARA NÃO APAGAR NA ABA "PEERS", GARANTA QUE VOCÊ ESTÁ NA ABA "ACTIVE PEERS"🔴 🔴 🔴
Fez tudo isso e ainda não pinga? Lembre-se da regra de ouro do Mikrotik: NAT vem antes do IPsec.
Se o tráfego da sua rede 172.20.0.0/24 estiver caindo na regra de Masquerade da saída da internet, ele nunca entrará no túnel com o IP correto.
Vá em IP > Firewall > NAT e crie uma regra de Accept (Bypass) no topo da lista:
Chain: srcnat
Src. Address: 172.20.0.0/24 (Sua rede)
Dst. Address: [Rede do Cliente]
Action: accept
Isso garante que o pacote chegue "limpo" até o motor do IPsec.
Espero que isso poupe as horas de debug que eu gastei por aqui!
DOCUMENTAÇÃO MIKROTIK: VPN IPSEC:
https://help.mikrotik.com/docs/spaces/ROS/pages/11993097/IPsec#:~:text=level%20(require%20%7C%20unique%20%7C%20use%3B%20Default%3A%20require)