VPN site-to-site com MikroTik e WireGuard: passo a passo

Ligar duas unidades da empresa, sede e filial, ou escritório e data center, é uma das tarefas mais comuns em rede corporativa. Com dois MikroTik no RouterOS 7, o WireGuard resolve isso com menos comandos e menos pontos de falha do que IPsec. Este guia mostra a configuração completa e comentada dos dois lados, com firewall, MTU, testes e erros comuns.

O que você vai montar #

O objetivo é uma VPN corporativa site-to-site: as estações da filial acessam os servidores da sede pela rede interna, como se estivessem no mesmo prédio, e o tráfego entre as duas redes passa cifrado pela internet. Cada roteador MikroTik ganha uma interface WireGuard, um peer apontando para o outro lado e uma rota para a rede remota.

Os IPs públicos são de documentação (RFC 5737) e as redes internas seguem a RFC 1918. Troque pelos da sua rede. As duas LANs não podem se sobrepor: se as duas unidades usam 192.168.0.0/24, renumere uma delas antes de começar.

Pré-requisitos #

Você precisa de dois roteadores MikroTik com RouterOS 7, acesso administrativo aos dois e pelo menos um lado alcançável pela internet em UDP. Confira também se as LANs não se sobrepõem e se a CPU dos modelos aguenta a banda cifrada que você espera, porque o WireGuard no MikroTik roda na CPU.

• RouterOS 7 nos dois lados, de preferência na mesma versão estável (/system package update check-for-updates). O RouterOS 6 não tem WireGuard.
• IP público em pelo menos um lado, ou encaminhamento da porta UDP no equipamento da operadora. Se a filial estiver atrás de CGNAT, veja a seção da variante mais abaixo.
• Backup da configuração antes de mexer: /export file=antes-da-vpn e /system backup save name=antes-da-vpn.
• Acesso fora de banda ou de recuperação (alguém no local, ou Safe Mode com Ctrl+X no terminal) caso uma regra de firewall corte seu acesso.
• Relógio e DNS corretos ajudam no diagnóstico pelos logs, embora o WireGuard não dependa de certificados.

Passo 1: criar as interfaces e trocar as chaves públicas #

Cada lado cria uma interface WireGuard, e o RouterOS gera o par de chaves automaticamente. A chave privada nunca sai do roteador. O que você copia de um lado para o outro é só a chave pública. Use a mesma porta nos dois lados para simplificar o firewall e o diagnóstico.

Na sede:

# Cria a interface WireGuard. A chave privada é gerada automaticamente.
/interface wireguard
add name=wg-filial listen-port=13231 mtu=1420 comment="VPN site-to-site: sede <-> filial"

# Mostra a chave pública desta ponta. Copie o valor para usar na filial.
/interface wireguard print proplist=name,listen-port,public-key

Na filial:

/interface wireguard
add name=wg-sede listen-port=13231 mtu=1420 comment="VPN site-to-site: filial <-> sede"

/interface wireguard print proplist=name,listen-port,public-key

Trate a saída de print sem proplist com cuidado: ela pode exibir a chave privada. Não cole essa saída em chamados, conversas ou documentação compartilhada.

Passo 2: cadastrar o peer de cada lado #

O peer diz ao roteador quem é o outro lado (chave pública), onde encontrá-lo (endpoint) e quais redes podem chegar por ele (allowed-address). O allowed-address funciona ao mesmo tempo como filtro de origem e como tabela de destinos do túnel: rede que não estiver ali é descartada.

Na sede:

/interface wireguard peers
add interface=wg-filial \
    public-key="" \
    endpoint-address=198.51.100.20 endpoint-port=13231 \
    allowed-address=10.255.255.2/32,192.168.20.0/24 \
    persistent-keepalive=25s \
    comment="Filial: aceita o IP de túnel e a LAN da filial"

Na filial:

/interface wireguard peers
add interface=wg-sede \
    public-key="" \
    endpoint-address=203.0.113.10 endpoint-port=13231 \
    allowed-address=10.255.255.1/32,192.168.10.0/24 \
    persistent-keepalive=25s \
    comment="Sede: aceita o IP de túnel e a LAN da sede"

O persistent-keepalive=25s mantém o estado de NAT aberto no caminho. Em links com IP público dos dois lados, ele é opcional, mas acelera a detecção de queda. Se quiser uma camada extra de proteção, gere uma chave pré-compartilhada e configure o mesmo valor em preshared-key nos dois peers.

Passo 3: endereços do túnel e rotas #

Com o peer cadastrado, cada interface recebe um IP no túnel e cada roteador ganha uma rota estática para a LAN do outro lado, apontando para a interface WireGuard. Sem a rota, o túnel sobe, o handshake acontece, mas nenhum pacote da LAN entra nele.

Na sede:

# IP da sede dentro do túnel (/30 = só dois endereços úteis)
/ip address
add address=10.255.255.1/30 interface=wg-filial comment="Túnel WG: lado sede"

# Tudo que for para a LAN da filial sai pelo túnel
/ip route
add dst-address=192.168.20.0/24 gateway=wg-filial comment="LAN da filial via WireGuard"

Na filial:

/ip address
add address=10.255.255.2/30 interface=wg-sede comment="Túnel WG: lado filial"

/ip route
add dst-address=192.168.10.0/24 gateway=wg-sede comment="LAN da sede via WireGuard"

Com várias filiais, cada uma recebe seu próprio /30 (ou um /24 de túnel compartilhado, com /32 por peer no allowed-address) e sua própria rota. Para muitas unidades, vale considerar OSPF sobre os túneis em vez de rotas estáticas.

Passo 4: firewall de entrada, encaminhamento e NAT #

O firewall precisa de três ajustes: aceitar o handshake na porta UDP do WireGuard (chain input), permitir o tráfego entre as duas LANs (chain forward) e garantir que esse tráfego não seja mascarado pelo NAT. As regras precisam ficar acima das regras de descarte da configuração padrão.

Na sede:

/ip firewall filter
# Aceita o handshake WireGuard vindo do IP público da filial
add chain=input action=accept protocol=udp dst-port=13231 src-address=198.51.100.20 \
    comment="WG: handshake da filial" place-before=0

# Permite tráfego entre as LANs nos dois sentidos
add chain=forward action=accept src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    comment="WG: filial -> sede" place-before=0
add chain=forward action=accept src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    comment="WG: sede -> filial" place-before=0

/ip firewall nat
# Impede que o tráfego entre as LANs seja mascarado (só necessário se o masquerade
# não estiver restrito a out-interface-list=WAN)
add chain=srcnat action=accept src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    comment="WG: sem NAT entre LANs" place-before=0

Na filial, o espelho:

/ip firewall filter
add chain=input action=accept protocol=udp dst-port=13231 src-address=203.0.113.10 \
    comment="WG: handshake da sede" place-before=0
add chain=forward action=accept src-address=192.168.10.0/24 dst-address=192.168.20.0/24 \
    comment="WG: sede -> filial" place-before=0
add chain=forward action=accept src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    comment="WG: filial -> sede" place-before=0

/ip firewall nat
add chain=srcnat action=accept src-address=192.168.20.0/24 dst-address=192.168.10.0/24 \
    comment="WG: sem NAT entre LANs" place-before=0

Depois de aplicar, confira a ordem com /ip firewall filter print e /ip firewall nat print. Se a política da empresa exigir, troque as regras de forward amplas por regras por serviço (por exemplo, só TCP 445 e 3389 para os servidores da sede).

MTU e MSS: o erro que só aparece em produção #

O WireGuard adiciona cabeçalho a cada pacote. Se o MTU do túnel for grande demais para o caminho, ping funciona, mas páginas web, compartilhamento de arquivos e RDP travam em transferências maiores. O padrão de 1420 bytes do RouterOS cobre WAN de 1500; em PPPoE, reduza e ajuste o MSS.

Para evitar que conexões TCP negociem segmentos maiores do que o túnel aguenta, ajuste o MSS nos dois roteadores:

/ip firewall mangle
# Ajusta o MSS dos pacotes SYN que saem e que entram pelo túnel
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn \
    out-interface=wg-filial passthrough=yes comment="WG: MSS saída"
add chain=forward action=change-mss new-mss=clamp-to-pmtu protocol=tcp tcp-flags=syn \
    in-interface=wg-filial passthrough=yes comment="WG: MSS entrada"

Na filial, troque wg-filial por wg-sede. Se o clamp-to-pmtu não resolver, use um valor fixo: MTU do túnel menos 40 (por exemplo, new-mss=1380 para MTU 1420).

Variante: filial sem IP público (CGNAT) #

Quando a filial está atrás de CGNAT ou de um modem que você não controla, ela não pode ser alcançada de fora. A solução é inverter a iniciativa: a filial chama a sede e mantém o túnel aberto com keepalive. A sede só precisa aceitar a conexão e aprender o endereço de origem.

Na sede, cadastre o peer sem endpoint-address (no lugar do comando do Passo 2) e crie a regra de entrada sem src-address, porque o IP público da filial muda:

/interface wireguard peers
# Sem endpoint: a sede aprende o IP de origem da filial no primeiro handshake
add interface=wg-filial \
    public-key="" \
    allowed-address=10.255.255.2/32,192.168.20.0/24 \
    comment="Filial (atrás de CGNAT)"

/ip firewall filter
# Aceita o handshake de qualquer origem na porta do WireGuard
add chain=input action=accept protocol=udp dst-port=13231 \
    comment="WG: handshake da filial (origem dinâmica)" place-before=0

Para conferir o endereço aprendido, veja current-endpoint-address em /interface wireguard peers print detail.

Na filial, mantenha endpoint-address=203.0.113.10 e persistent-keepalive=25s. Abrir a porta UDP 13231 para qualquer origem é aceitável no WireGuard: o roteador não responde a pacotes que não venham de um peer com chave válida. Se o IP da sede for dinâmico, use um nome DNS no endpoint-address da filial.

Teste e diagnóstico #

Teste em camadas: primeiro o handshake, depois o ping entre os IPs de túnel, depois o ping entre as LANs e, por fim, uma transferência grande. Cada camada que falha aponta para uma parte diferente da configuração, e pular etapas é o que transforma dez minutos de diagnóstico em uma tarde.

# 1. Handshake: last-handshake deve ser de poucos segundos ou minutos atrás,
#    e rx/tx devem crescer
/interface wireguard peers print detail

# 2. Ping entre os IPs de túnel (na sede)
/ping 10.255.255.2 count=5

# 3. Ping entre LANs, usando o IP da LAN como origem
/ping 192.168.20.1 src-address=192.168.10.1 count=5

# 4. Caminho: o primeiro salto deve ser o túnel
/tool traceroute 192.168.20.1 src-address=192.168.10.1

# 5. MTU: deve passar com 1420 e falhar acima disso
/ping 192.168.20.1 src-address=192.168.10.1 size=1420 do-not-fragment count=3

# 6. Os pacotes UDP estão chegando na WAN?
/tool sniffer quick port=13231

# 7. Logs do WireGuard (desative depois do diagnóstico)
/system logging add topics=wireguard action=memory
/log print

Por fim, teste de uma estação da filial: acesse um compartilhamento ou sistema da sede e copie um arquivo de algumas centenas de megabytes. Se o ping passa e a cópia trava, volte à seção de MTU e MSS.

Erros comuns #

As causas mais frequentes de problema com WireGuard no MikroTik são cinco: chave trocada, allowed-address incompleto, rota faltando, firewall bloqueando ou MTU grande demais. A tabela relaciona cada sintoma com a causa provável e o comando ou ponto da configuração onde olhar primeiro, na ordem em que vale a pena verificar.

Quando contratar #

Configurar um túnel entre duas unidades é tarefa que um técnico com acesso aos dois roteadores faz em uma tarde, seguindo este guia. Vale chamar ajuda quando há muitas unidades, redes sobrepostas, sistemas críticos dependendo do link, ou quando ninguém vai documentar e monitorar o túnel depois.

Situações em que o projeto pede mais do que este passo a passo:

• Cinco ou mais unidades, em que rotas estáticas viram manutenção e OSPF ou um desenho em estrela com redundância fazem diferença.
• Link redundante com failover entre duas operadoras.
• Redes sobrepostas que exigem renumeração ou NAT entre sites.
• Segmentação: a filial só pode acessar o ERP, e não a rede inteira da sede.
• Monitoramento e documentação: alerta quando o túnel cai e diagrama atualizado para quem vier depois.

A SDI faz projeto e implantação de redes e segurança com MikroTik e Cisco, incluindo VPN corporativa site-to-site e acesso remoto de colaboradores. A entrega inclui o diagrama da rede, o export comentado da configuração e as credenciais em nome da sua empresa.

• mikrotik
• wireguard
• routeros
• vpn
• firewall
• redes