Um assinante relata que algumas páginas ficam pela metade ao carregar, que a VPN do escritório conecta mas nunca passa tráfego, e que requisições pequenas funcionam bem enquanto qualquer coisa com mais conteúdo simplesmente dá timeout. O ping para o mesmo host funciona perfeitamente. Essa é a assinatura clássica de um problema de MTU em um link PPPoE, e quase nunca aparece como "a internet caiu" — aparece como "algumas coisas funcionam e outras não", exatamente por isso é confundido no início com um problema de roteamento ou de DNS.
Entenda por que o PPPoE causa isso de cara
O Ethernet carrega até 1500 bytes de payload. O PPPoE adiciona seu próprio cabeçalho de 8 bytes dentro desse frame, deixando só 1492 bytes para tudo o que vem acima — então o equipamento de um assinante que ainda assume um MTU de caminho de 1500 bytes envia pacotes grandes demais para o link PPPoE. Normalmente o roteador responderia com uma mensagem ICMP de "fragmentação necessária" para quem enviou ajustar o tamanho, um mecanismo chamado Path MTU Discovery. O problema é que muitos firewalls, tanto do lado do assinante quanto na internet, bloqueiam ICMP diretamente — então essa mensagem de correção nunca chega, e o pacote grande demais simplesmente é descartado em silêncio repetidas vezes.
Entenda por que isso afeta mais o tráfego TCP
Requisições pequenas — uma consulta DNS, um ping, o início de um handshake TCP — cabem sem problema abaixo dos 1492 bytes, por isso a conectividade básica parece boa. Só quando uma sessão TCP tenta empurrar um segmento de tamanho completo — exatamente o que acontece ao carregar uma página com conteúdo real ou ao empurrar dados por um túnel VPN — é que o pacote grande demais esbarra no link PPPoE e desaparece sem nenhum erro reportado. Esse contraste — "o ping funciona, navegar não" — é a pista.
Adicione uma regra de MSS clamping no mangle
Em vez de esperar que o Path MTU Discovery funcione (o que exige cooperação de redes que você não controla), reduza o TCP MSS na saída para que cada pacote SYN já anuncie um tamanho de segmento que caiba dentro do MTU do PPPoE:
/ip firewall mangle add chain=forward tcp-flags=syn protocol=tcp \
action=change-mss new-mss=clamp-to-pmtuclamp-to-pmtu é preferível a um número fixo como new-mss=1400 — o RouterOS calcula o valor correto por interface automaticamente, o que importa assim que você tem assinantes com encapsulamentos diferentes (PPPoE, Ethernet simples, WireGuard) atrás do mesmo roteador.
Aplique na interface que realmente precisa disso
A regra acima roda em toda conexão encaminhada, o que é aceitável para uma implantação pequena, mas em um concentrador de acesso com centenas de sessões PPPoE vale a pena restringi-la só à lista de interfaces PPPoE, para não fazer trabalho desnecessário em tráfego de assinantes que nunca teria esse problema:
/interface list add name=pppoe-clients
/ip firewall mangle add chain=forward tcp-flags=syn protocol=tcp \
out-interface-list=pppoe-clients action=change-mss new-mss=clamp-to-pmtuConfirme a correção com uma transferência real, não só com ping
O ping nunca ia mostrar esse problema, então também não consegue confirmar a correção. Carregue uma página com conteúdo real, ou use /tool traceroute combinado com um teste de payload grande — o cliente VPN afetado ou o site que antes ficava pela metade ao carregar é o teste de verdade. Se agora carrega direito e a VPN passa tráfego, a regra de clamp está funcionando.
Por que fazer assim
A alternativa ao MSS clamping é dizer para cada assinante baixar manualmente o MTU do próprio equipamento para 1492, o que não escala, não sobrevive a um reset do dispositivo, e não serve de nada em equipamentos do assinante que você não controla. O MSS clamping resolve no único ponto que você de fato controla — o seu próprio roteador — garantindo que as sessões TCP nunca negociem um tamanho de segmento grande demais para o caminho, então não sobra nada para uma mensagem ICMP bloqueada precisar corrigir. É uma regra de mangle de cinco minutos que elimina toda uma categoria de chamados de "algumas coisas não funcionam" genuinamente difíceis de diagnosticar só pelo sintoma.
Como o MoniTik ajuda
Esse tipo de problema é invisível para um monitoramento básico por ping justamente porque o ping continua funcionando — o link aparece no ar enquanto o assinante está realmente travado. Os gráficos de tráfego por interface do MoniTik facilitam identificar a assinatura real: uma conexão alcançável mas com throughput incomumente baixo ou padrões de transferência erráticos comparados à sua base normal, uma pista bem melhor para um problema de MTU do que esperar uma ligação de suporte sobre uma VPN que "simplesmente não funciona".
Valentina passou a última década implantando e resolvendo problemas em redes MikroTik para provedores de toda a América Latina.