Como Configurar VPN WireGuard no MikroTik: Passo a Passo Completo

O WireGuard chegou ao RouterOS na versão 7.1 e rapidamente se tornou o protocolo de VPN preferido para interligar roteadores MikroTik. É mais rápido que OpenVPN, mais simples que IPSec, usa criptografia moderna (ChaCha20, Curve25519, BLAKE2) e funciona mesmo em redes instáveis.

Neste tutorial, você vai configurar um túnel VPN WireGuard site-to-site entre dois roteadores MikroTik — um cenário clássico para interligar matriz com filial ou acesso remoto à rede de um cliente.

Pré-requisitos

• RouterOS 7.1 ou superior em ambos os roteadores
• Pelo menos um dos roteadores com IP público acessível (ou use um relay — explicado no final)
• Acesso root/admin em ambos
• Portas UDP liberadas no firewall (padrão WireGuard: 13231, mas pode ser qualquer porta)

Arquitetura do túnel

No exemplo deste tutorial:

• Roteador A (Servidor/Hub): IP público 203.0.113.1 — porta WireGuard 13231
• Roteador B (Cliente/Spoke): atrás de CGNAT ou IP dinâmico — inicia a conexão
• Rede do Roteador A: 192.168.1.0/24
• Rede do Roteador B: 192.168.2.0/24
• Endereços do túnel: 10.0.0.1/30 (A) e 10.0.0.2/30 (B)

Configuração passo a passo

# No Roteador A — criar interface WireGuard
# O RouterOS gera automaticamente o par de chaves
/interface wireguard add \
  name=wg-site \
  listen-port=13231

# Visualizar a chave pública gerada
/interface wireguard print
# Anote o valor de "public-key" — você precisará dele no Roteador B

# No Roteador B — criar interface WireGuard
/interface wireguard add \
  name=wg-site \
  listen-port=13231

# Anote a chave pública do Roteador B também
/interface wireguard print

# No Roteador A
/ip address add \
  address=10.0.0.1/30 \
  interface=wg-site

# No Roteador B
/ip address add \
  address=10.0.0.2/30 \
  interface=wg-site

# No Roteador A — adicionar Roteador B como peer
/interface wireguard peers add \
  interface=wg-site \
  public-key="CHAVE_PUBLICA_DO_ROTEADOR_B" \
  allowed-address=10.0.0.2/32,192.168.2.0/24 \
  persistent-keepalive=25

# No Roteador B — adicionar Roteador A como peer
/interface wireguard peers add \
  interface=wg-site \
  public-key="CHAVE_PUBLICA_DO_ROTEADOR_A" \
  endpoint-address=203.0.113.1 \
  endpoint-port=13231 \
  allowed-address=10.0.0.1/32,192.168.1.0/24 \
  persistent-keepalive=25

# No Roteador A — rota para a rede do Roteador B
/ip route add \
  dst-address=192.168.2.0/24 \
  gateway=10.0.0.2

# No Roteador B — rota para a rede do Roteador A
/ip route add \
  dst-address=192.168.1.0/24 \
  gateway=10.0.0.1

# No Roteador A (o que recebe conexões)
/ip firewall filter add \
  chain=input \
  protocol=udp \
  dst-port=13231 \
  action=accept \
  comment="WireGuard VPN" \
  place-before=0

Verificar se o túnel está funcionando

# Verificar status do peer — "last-handshake" deve aparecer
/interface wireguard peers print

# Testar conectividade pelo túnel
/ping 10.0.0.2          # IP do túnel do Roteador B
/ping 192.168.2.1       # Gateway da rede do Roteador B

Se o last-handshake mostrar um timestamp recente (menos de 2 minutos) e o ping responder, o túnel está ativo.

Cenário CGNAT: ambos sem IP público

Quando nenhum dos dois roteadores tem IP público (ambos atrás de CGNAT), a conexão direta não é possível. As opções são:

1. Contratar IP fixo — solução mais simples, custo adicional com a operadora
2. VPS como relay — um servidor com IP público no meio, fazendo o papel de concentrador
3. DDNS + port-forwarding no roteador da operadora — funciona em CGNAT leve (CGN sem mapeamento duplo)
4. Plataforma com relay integrado — como o Mikrosinc, que provisiona automaticamente o túnel mesmo em CGNAT total sem exigir VPS ou IP fixo

Erros comuns e como resolver

Handshake não estabelece

• Verifique se a porta UDP 13231 está liberada no firewall do Roteador A
• Confirme que as chaves públicas foram copiadas corretamente (sem espaços extras)
• Teste se o IP/porta do endpoint está acessível: /tool tcp-ping 203.0.113.1 13231

Handshake estabelece mas ping não funciona

• Verifique se as rotas foram adicionadas corretamente em ambos os lados
• Confirme que o allowed-address inclui a subnet da rede remota
• Verifique se há regras de firewall bloqueando tráfego na interface wg-site

Túnel cai após alguns minutos

• Ative o persistent-keepalive=25 no peer que está atrás de NAT
• Verifique se o roteador com IP público não está reiniciando a interface