Un abonado reporta que algunas páginas se quedan a mitad de cargar, que la VPN de la oficina conecta pero nunca pasa tráfico, y que los pedidos chicos andan bien mientras que cualquier cosa con más contenido simplemente hace timeout. El ping al mismo host anda perfecto. Esta es la firma clásica de un problema de MTU en un enlace PPPoE, y casi nunca se presenta como "no tengo internet" — se presenta como "algunas cosas andan y otras no", que es justo por qué al principio se lo confunde con un problema de ruteo o de DNS.
Entendé por qué PPPoE causa esto de entrada
Ethernet transporta hasta 1500 bytes de payload. PPPoE agrega su propio header de 8 bytes dentro de ese frame, dejando solo 1492 bytes para todo lo que va arriba — así que el equipo de un abonado que todavía asume un MTU de camino de 1500 bytes manda paquetes demasiado grandes para el enlace PPPoE. Normalmente el router respondería con un mensaje ICMP de "fragmentación necesaria" para que quien envía ajuste el tamaño, un mecanismo llamado Path MTU Discovery. El problema es que muchos firewalls, tanto del lado del abonado como en internet, bloquean ICMP directamente — así que ese mensaje de corrección nunca llega, y el paquete demasiado grande simplemente se descarta en silencio una y otra vez.
Entendé por qué esto golpea más fuerte al tráfico TCP
Los pedidos chicos — una consulta DNS, un ping, el inicio de un handshake TCP — entran sin problema debajo de los 1492 bytes, por eso la conectividad básica se ve bien. Recién cuando una sesión TCP intenta empujar un segmento de tamaño completo — justo lo que pasa al cargar una página con contenido real o al empujar datos por un túnel VPN — el paquete demasiado grande choca contra el enlace PPPoE y desaparece sin que se reporte ningún error. Ese contraste — "el ping anda, navegar no" — es la pista.
Agregá una regla de MSS clamping en mangle
En vez de esperar a que Path MTU Discovery funcione (lo cual requiere cooperación de redes que no controlás), recortá el TCP MSS a la salida para que cada paquete SYN ya anuncie un tamaño de segmento que entre dentro del MTU de PPPoE:
/ip firewall mangle add chain=forward tcp-flags=syn protocol=tcp \
action=change-mss new-mss=clamp-to-pmtuclamp-to-pmtu es preferible a un número fijo como new-mss=1400 — RouterOS calcula el valor correcto por interfaz automáticamente, algo que importa en cuanto tenés abonados con distintas encapsulaciones (PPPoE, Ethernet plano, WireGuard) detrás del mismo router.
Aplicala en la interfaz que realmente la necesita
La regla de arriba corre en cada conexión reenviada, lo cual está bien para un despliegue chico, pero en un concentrador de acceso con cientos de sesiones PPPoE vale la pena acotarla solo a la lista de interfaces PPPoE para que no esté haciendo trabajo de más sobre tráfico de abonados que nunca iba a tener el 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-pmtuConfirmá el arreglo con una transferencia real, no solo con ping
El ping nunca iba a mostrar este problema, así que tampoco puede confirmar el arreglo. Cargá una página con contenido real, o usá /tool traceroute combinado con una prueba de payload grande — el cliente VPN afectado o el sitio que antes se quedaba a mitad de cargar es la prueba real. Si ahora carga bien y la VPN pasa tráfico, la regla de clamp está haciendo su trabajo.
Por qué hacerlo así
La alternativa a MSS clamping es decirle a cada abonado que baje manualmente el MTU de su equipo a 1492, algo que no escala, no sobrevive a un reset del dispositivo, y no sirve de nada con equipos del abonado que no controlás. MSS clamping lo arregla en el único punto que sí controlás — tu propio router — asegurando que las sesiones TCP nunca negocien un tamaño de segmento demasiado grande para el camino, así no queda nada que un mensaje ICMP bloqueado tenga que corregir. Es una regla de mangle de cinco minutos que elimina toda una categoría de tickets de "algunas cosas no andan" que son genuinamente difíciles de diagnosticar solo a partir del síntoma.
Cómo te ayuda MoniTik
Este tipo de problema es invisible para un monitoreo básico por ping justamente porque el ping sigue andando — el enlace se ve arriba mientras el abonado está realmente trabado. Los gráficos de tráfico por interfaz de MoniTik hacen más fácil detectar la firma real: una conexión alcanzable pero con throughput inusualmente bajo o patrones de transferencia erráticos comparados con su base habitual, una pista mucho mejor hacia un problema de MTU que esperar un llamado de soporte sobre una VPN que "simplemente no anda".
Valentina lleva una década implementando y resolviendo problemas en redes MikroTik para ISPs de toda Latinoamérica.