Para que serve a porta 51820
A documentação do WireGuard é direta: todos os pacotes são enviados sobre UDP. A porta de escuta é definida em ListenPort na configuração do servidor (ou com wg set wg0 listen-), e cada cliente aponta para ela no campo Endpoint.
Uma característica importante para quem testa: o servidor não responde a nada que não esteja autenticado com uma chave conhecida. Segundo a descrição do protocolo, um cliente não autorizado não recebe resposta alguma; o servidor fica silencioso e invisível.
Quem usa a porta 51820 na prática:
- Acesso remoto à rede de casa ou da empresa
- Servidor WireGuard em roteadores, NAS, VPS e mini PCs
- VPNs em malha que usam WireGuard por baixo
- Ligação entre redes de duas sedes (site a site)
O que diz o registro da IANA
A 51820 está na faixa de portas dinâmicas e privadas (49152 a 65535), que a RFC 6335 define como nunca atribuída pela IANA. Ela virou padrão de fato por aparecer nos exemplos da documentação oficial do WireGuard.
Como não há registro, outros programas podem usar o mesmo número. Se a porta 51820 aparecer aberta no seu IP sem que você rode o serviço descrito aqui, confira qual programa está escutando nela.
É seguro deixar a porta 51820 aberta?
Como o servidor não responde a pacotes não autenticados, a 51820 nem aparece como aberta para quem varre a internet. O cuidado está nas chaves: guarde a chave privada de cada aparelho, remova o par (peer) de um aparelho perdido e mantenha o software atualizado.
Como abrir a porta 51820 com segurança
Redirecione a UDP 51820 para o IP do servidor WireGuard (ou ative o servidor WireGuard do próprio roteador, se houver). No servidor, libere a porta no firewall e, se os clientes devem acessar a rede inteira, ative o encaminhamento de pacotes (IP forwarding).
Atrás de CGNAT, nenhum servidor VPN em casa recebe conexões, porque o roteador não tem IP público. As saídas são pedir um IP público à operadora, usar IPv6 (liberando a porta no firewall IPv6 do roteador) ou recorrer a uma VPN em malha que atravessa NAT, como as baseadas em WireGuard.
Passo a passo para a porta 51820
- 1
Reserve um IP fixo para o aparelho
Descubra o IP local do aparelho que vai receber as conexões (no Windows, comipconfig; em celulares, consoles e câmeras, nos detalhes da rede) e crie uma reserva de DHCP no roteador. Assim a regra não deixa de funcionar quando o IP mudar. - 2
Entre no painel do roteador
Acesse o endereço do gateway, em geral 192.168.0.1 ou 192.168.1.1 (alguns roteadores de operadoras usam outros, como 192.168.15.1), com a senha da etiqueta ou a que você definiu. Veja como encontrar o endereço em como descobrir o IP do roteador e os guias por marca em IPs de roteador. - 3
Crie a regra para a porta 51820
Procure por “Redirecionamento de portas”, “Encaminhamento de portas”, “Servidor virtual”, “NAT” ou “Port forwarding”, conforme o modelo. Informe porta externa 51820, porta interna 51820, protocolo UDP e o IP reservado no passo 1. O passo a passo detalhado está em como abrir portas no roteador. - 4
Libere a porta no firewall do aparelho
Mesmo com o roteador configurado, o firewall do sistema pode descartar a conexão. Use os comandos abaixo, como administrador. - 5
Teste de fora da rede
O verificador do site testa TCP e não confirma portas UDP. Teste conectando um cliente de fora da rede, pelo 4G do celular, por exemplo.
New-NetFirewallRule -DisplayName "Porta 51820 UDP" -Direction Inbound -Protocol UDP -LocalPort 51820 -Action Allowsudo ufw allow 51820/udpComo testar a porta 51820
O verificador de portas testa TCP, e o WireGuard só usa UDP e ainda por cima não responde a estranhos, então o resultado “fechada” é esperado e não indica problema. O teste real é conectar um cliente pela rede móvel e rodar wg show no servidor: se aparecer “latest handshake” recente para aquele cliente, a porta está funcionando.
Antes de culpar o roteador, confirme que algum programa está mesmo escutando na porta 51820 no aparelho:
netstat -ano | findstr :51820sudo ss -tulpn | grep :51820Problemas comuns com a porta 51820
Sem handshake: o cliente envia, mas nada volta
Confira, nesta ordem: regra UDP 51820 no roteador apontando para o servidor, firewall do servidor, IP público ou nome no Endpoint do cliente, chaves públicas trocadas corretamente e se a conexão do servidor está atrás de CGNAT.
Conecta, mas não navega nem acessa a rede
O túnel está de pé, mas o tráfego não é encaminhado. Revise o AllowedIPs dos dois lados, o IP forwarding no servidor e as regras de NAT ou de rota para a faixa da VPN.
A porta continua fechada mesmo com a regra criada
Se nada acima resolveu, as causas abaixo valem para qualquer porta:
- A conexão está atrás de CGNAT. Se o IP da WAN no painel do roteador está na faixa 100.64.0.0/10 (de 100.64.0.0 a 100.127.255.255) ou é diferente do IP que aparece em meu IP, a operadora compartilha o IP público entre vários clientes e nenhuma porta aberta no roteador será alcançada de fora. Confirme no teste de CGNAT e peça um IP público à operadora. Entenda o assunto em o que é CGNAT.
- Firewall do sistema ou antivírus. O Firewall do Windows, o ufw no Linux e alguns antivírus bloqueiam conexões de entrada por padrão. Crie a regra para a porta ou para o programa e teste de novo.
- Dois roteadores em sequência (NAT duplo). Com o modem da operadora e um roteador seu ligados em sequência, a regra precisa existir nos dois, ou o equipamento da operadora deve ficar em modo bridge.
- Teste feito de dentro da própria rede. Muitos roteadores não deixam um aparelho da rede acessar o próprio IP público (NAT loopback), e o teste falha mesmo com tudo certo. Teste de fora, pelo 4G do celular ou pelo verificador de portas.
- Bloqueio da operadora. Algumas portas são filtradas por política em conexões residenciais (no Brasil, a saída pela 25) e outras podem ser bloqueadas conforme o plano. Se todo o resto estiver certo, pergunte ao suporte da operadora; a página de operadoras reúne informações por provedor.