Como Configurar WireGuard no MikroTik (RouterOS)

Sua VPN de acesso remoto ainda roda em PPTP? Em outubro de 2024 a Microsoft anunciou a depreciação oficial do protocolo — no Windows Server 2025, novas instalações de RRAS já não habilitam PPTP/L2TP por padrão (fonte: Group-IB). Neste artigo mostramos, comando a comando, como configurar um servidor WireGuard no MikroTik RouterOS 7 e migrar sua VPN para um protocolo moderno, com segmentação de acesso real — não apenas troca de porta.

Por que sair do PPTP agora

PPTP usa criptografia MPPE baseada em RC4 e autenticação MS-CHAPv2, ambas quebradas há anos e amplamente documentadas. A Apple já removeu o suporte nativo em seus sistemas, e a depreciação anunciada pela Microsoft em 2024 formaliza o que a comunidade de segurança já apontava: manter a porta 1723/TCP e o protocolo GRE expostos na internet é manter uma porta de entrada conhecida.

O WireGuard resolve isso com um desenho mais simples: criptografia moderna (ChaCha20-Poly1305, Curve25519), código enxuto, e suporte nativo no RouterOS 7.x — sem pacote adicional, sem licença extra.

Pré-requisitos: valide o caminho até o roteador antes de abrir a porta

Antes de criar qualquer interface, confirme como o MikroTik está exposto à internet:

Se ddns-enabled=yes, o campo dns-name retornado é o endpoint que você vai usar nos clientes — acompanha o IP público automaticamente em links dinâmicos. Mas DDNS resolve mudança de IP, não elimina CGNAT. O DDNS pode apontar certinho para o IP público e, mesmo assim, a porta UDP nunca chegar ao MikroTik, se houver um modem/roteador da operadora fazendo NAT antes dele. Confirme em /ip address print se o WAN recebe IP público diretamente — caso contrário, o redirecionamento de porta precisa ser feito também nesse equipamento anterior. O próprio /ip cloud geralmente já sinaliza um aviso quando detecta esse cenário.

Backup real antes de mexer no firewall

/export sozinho não é backup — é a representação textual da configuração, útil para consulta, mas não restaura o sistema como um backup binário completo:

O primeiro gera um .backup binário (restaurável via /system backup load); o segundo, o .rsc textual. Em acesso remoto, mexendo no firewall input, use Safe Mode (Ctrl+X no terminal, ou botão no WinBox) — qualquer mudança que derrube seu próprio acesso é revertida automaticamente se a sessão cair antes da confirmação.

Criando a interface WireGuard no RouterOS

O RouterOS gera automaticamente o par de chaves da interface — não existe comando separado de “gerar chave”. Sobre os campos:

• name — identificador da interface no roteador.
• listen-port — porta UDP em que o servidor escuta. Se você omitir esse parâmetro, o RouterOS atribui 13231 automaticamente. 51820 não é o padrão do RouterOS — é a porta convencionalmente associada ao WireGuard na documentação oficial do projeto e em outras implementações (Linux, por exemplo). Qualquer porta UDP livre funciona.
• mtu — 1420 é o valor padrão que o próprio RouterOS assume para interfaces WireGuard. Ajuste para baixo (ex: 1380-1400) se notar fragmentação ou timeouts em links com overhead adicional (PPPoE, alguns links 4G).

Para capturar a chave pública gerada:

O campo public-key do retorno entra no arquivo de configuração de cada cliente, no bloco [Peer], como identificação do servidor.

Endereçando a interface e liberando a porta (chain input)

Esse endereço é a rede interna da VPN — a faixa de onde os clientes remotos recebem IP. Use uma faixa que não colida com nenhuma VPN legada já existente nem com a LAN local.

O parâmetro place-before insere a regra imediatamente antes da regra indicada. Esse comando pressupõe que exista exatamente uma regra com o comentário informado no seu firewall — não é copy/paste universal. Antes de usar, rode /ip firewall filter print e confirme o comentário exato da sua última regra de drop, ou insira a regra sem place-before e reposicione manualmente com /ip firewall filter move [find comment="WireGuard"] destination=<número-da-regra-de-drop>.

Essa regra libera o input — ou seja, permite que o próprio MikroTik receba o pacote de handshake. Isso não é suficiente sozinho.

Liberando o tráfego do cliente para a LAN (chain forward)

Input e forward protegem coisas diferentes: chain=input controla o que chega ao próprio roteador; chain=forward controla o que o roteador repassa entre redes — nesse caso, do túnel WireGuard para a LAN interna. O handshake pode funcionar perfeitamente (túnel “de pé”) e, ainda assim, o cliente não conseguir acessar nada na LAN se o forward estiver bloqueando.

Verifique se sua chain=forward tem alguma regra de drop no final. Se não tiver nenhuma (política implícita de aceitar), o tráfego já passa. Se houver uma regra de drop geral em forward, adicione explicitamente antes dela:

Criando peers (clientes)

Diferente de PPTP e SSTP, o WireGuard não autentica por usuário e senha, e por isso não usa /ip pool. A identidade de cada cliente é a própria chave pública, e o endereço é fixado manualmente:

• interface — a qual interface WireGuard esse peer pertence.
• public-key — a chave pública gerada no dispositivo do cliente (nunca a privada).
• allowed-address — define quais prefixos de origem o roteador aceita e roteia para aquele peer específico, sempre em /32 para um único host. Isso não isola automaticamente um peer do outro — allowed-address é uma regra de roteamento/aceite, não uma política de segurança. O isolamento entre usuários da VPN é responsabilidade do firewall, na próxima seção.

Controle o que o usuário da VPN pode acessar

Sem regras adicionais, todo peer criado enxerga a LAN inteira e, dependendo da topologia, pode até alcançar outro peer. Para um ambiente com dados sensíveis (contábil, financeiro), trate a VPN como rede não confiável por padrão e libere só o necessário:

Em ordem: a primeira regra libera acesso só ao IP do servidor necessário; a segunda bloqueia peer tentando alcançar outro peer diretamente pelo próprio túnel; a terceira é o “resto proibido” — qualquer coisa que não bateu nas regras anteriores é negada. Ajuste o dst-address conforme os sistemas que cada grupo de usuário realmente precisa acessar.

Instalando o cliente (Windows e Linux)

Windows: baixe o instalador oficial direto do site do projeto: download.wireguard.com/windows-client/wireguard-installer.exe. Instale, abra o aplicativo e escolha “Adicionar túnel → Criar do zero” — o programa gera a chave privada/pública localmente e você só precisa colar o restante do arquivo (próxima seção).

Linux (Debian/Ubuntu): instale o pacote:

No Linux não existe app gráfico gerando a chave sozinho — gere manualmente:

wg genkey cria a chave privada e imprime no terminal; o tee salva essa saída no arquivo privatekey e repassa para o wg pubkey, que deriva a chave pública correspondente e grava em publickey. O umask 077 garante que os arquivos sejam criados com permissão restrita desde o início.

Crie o arquivo de configuração (conteúdo detalhado na próxima seção):

Ative o túnel:

Distribuições como Fedora, Arch e CentOS têm pacotes próprios — lista completa por distro na página oficial: wireguard.com/install.

Configuração do cliente — formato pronto

• PrivateKey — chave privada local; nunca compartilhar.
• Address — o mesmo IP definido no allowed-address do peer no servidor.
• DNS — use o DNS corporativo (controlador de domínio, servidor de arquivos) acessível pelo próprio túnel, não um DNS público. DNS público não resolve nomes internos (ex: srv-arquivos.local), e é justamente esse tipo de acesso que a VPN corporativa existe para viabilizar.
• PublicKey (bloco Peer) — chave pública do servidor, de /interface wireguard print.
• Endpoint — endereço público ou DDNS do servidor, seguido de :porta.
• AllowedIPs — quais redes passam pelo túnel. Evite exemplos genéricos como 192.168.1.0/24 em material público: se a rede residencial do usuário remoto usar a mesma faixa que a empresa, o split tunnel pode rotear tráfego para a interface errada. Use sempre a faixa real da sua LAN.
• PersistentKeepalive — em segundos, envia pacotes periódicos para manter o mapeamento de NAT vivo. É útil quando o cliente está atrás de NAT (a maioria dos casos em rede residencial/4G) e precisa continuar recebendo tráfego iniciado pelo servidor após período ocioso — não é obrigatório para todo cenário, mas raramente atrapalha.

Validando o túnel — sequência completa

Handshake sozinho não confirma que tudo funciona ponta a ponta. Siga a sequência:

1. last-handshake preenchido e recente (segundos de idade) — confirma que as chaves batem e o pacote UDP chegou.
2. rx/tx aumentando a cada nova checagem — confirma tráfego real passando, não só negociação inicial.
3. ping do cliente para um host interno com ICMP liberado, ex: ping 192.168.1.1.
4. Resolução DNS interna — do cliente, tente resolver um hostname interno (ex: nslookup srv-arquivos.local) para confirmar que o DNS configurado está acessível pelo túnel.
5. Teste da aplicação real — acesso RDP, compartilhamento de arquivo ou sistema que o usuário efetivamente vai usar.
6. Confirme o split tunnel — com o túnel ativo, verifique que a navegação normal do usuário (sites, e-mail) continua saindo pelo link dele, não pelo MikroTik — isso depende do seu AllowedIPs estar restrito à LAN, e não em 0.0.0.0/0.

Se o last-handshake não aparecer depois de 15-20 segundos, as causas mais comuns são, nessa ordem de probabilidade: porta fechada no firewall (chain input), endpoint incorreto no cliente, CGNAT entre o roteador e a internet, ou chave pública divergente entre servidor e cliente — chave errada impede a autenticação do par e nunca gera handshake válido.

Perguntas frequentes

PPTP ainda funciona depois de configurar o WireGuard no MikroTik?
Sim, coexistem sem conflito, desde que usem portas e faixas de IP diferentes. Mantenha o PPTP ativo até validar o WireGuard com os usuários reais por alguns dias antes de desativar o protocolo legado.

Por que o WireGuard não usa /ip pool como o PPTP?
Porque o modelo de conexão é diferente. PPTP autentica por usuário/senha e recebe IP dinâmico de um pool. O WireGuard identifica o peer pela chave pública e o IP é fixado manualmente na criação do peer — não existe atribuição dinâmica nativa no protocolo.

allowed-address em /32 já isola os usuários da VPN entre si?
Não sozinho. Esse campo define o roteamento aceito para aquele peer, não uma política de isolamento. Para impedir que um peer alcance outro, é necessário regra explícita de firewall em chain=forward, como mostrado na seção de controle de acesso deste artigo.

Migrar de PPTP para WireGuard no MikroTik, com segmentação de acesso correta, leva pouco mais de uma hora e elimina uma das portas de entrada mais exploradas em ambientes de pequenas e médias empresas. Se sua empresa ainda depende de VPN legada e quer migrar com segurança, fale com a gente no WhatsApp.