Packet Sniffer de MikroTik permite observar paquetes que recibe, envía o reenvía el router. Es útil para responder una pregunta concreta durante una asistencia: ¿la solicitud del cliente está llegando al MikroTik y aparece tráfico de respuesta?
En esta guía aprenderás a utilizarlo desde Tools → Packet Sniffer y desde la terminal, a combinar filtros por IP, interfaz y puerto, y a leer lo esencial de una captura. El análisis detallado de TCP, retransmisiones y errores quedará para una segunda entrada.
¿Qué es Packet Sniffer y para qué sirve en MikroTik?
Un sniffer captura tráfico en un punto de la red. En RouterOS puedes usarlo para comprobar si llega una consulta DNS, si un equipo intenta conectarse a un servicio o por qué interfaz aparece una comunicación.
Por ejemplo, si un cliente dice que una aplicación no conecta, puedes observar el puerto que utiliza. Encontrar el paquete ayuda a ubicar hasta dónde llegó el intento; después debes seguir su recorrido y revisar la respuesta.
1. Cómo usar Packet Sniffer desde WinBox
La interfaz gráfica resulta cómoda para configurar una captura sin memorizar comandos.
- Conéctate al MikroTik por WinBox.
- Abre Tools → Packet Sniffer.
- En la configuración y filtros, selecciona la interfaz donde esperas encontrar el tráfico.
- Completa la IP, el protocolo y el puerto que deseas observar. Deja vacíos los filtros ajenos a la prueba.
- Aplica los cambios y pulsa Start.
- Desde el dispositivo afectado, reproduce el problema.
- Pulsa Stop y abre la lista de Packets para revisar los paquetes capturados.
Según la versión de WinBox, la configuración puede aparecer en pestañas, paneles o ventanas separadas. Estos son los valores del ejemplo que desarrollaremos más adelante:
| Campo | Valor del ejemplo |
|---|---|
| Interface | ether2-LAN |
| IP Address | 192.168.10.50/32 |
| IP Protocol | udp |
| Port | 53 |
| Direction | any, para observar ambos sentidos |
Sustituye la interfaz y la IP por las de tu red. Si el cliente entra por un bridge, una VLAN o una sesión PPPoE, selecciona el punto lógico o físico adecuado para la prueba.
2. Cómo usar Packet Sniffer mediante comandos
La terminal es especialmente versátil para soporte: puedes copiar una prueba, cambiar un filtro y comparar interfaces con rapidez. Abre New Terminal en WinBox o accede mediante SSH.
Consultar la configuración actual
/tool sniffer printEste comando muestra los ajustes actuales. No inicia una captura ni enumera todos los argumentos posibles de cada comando.
Ver tráfico en tiempo real con quick
/tool sniffer quick interface=ether2-LAN ip-address=192.168.10.50/32Para limitarlo a una consulta DNS por UDP:
/tool sniffer quick interface=ether2-LAN ip-address=192.168.10.50/32 ip-protocol=udp port=53 direction=anyDetén la vista con Q o Ctrl+C. Si aparece already running, comprueba si hay otra captura en curso; finalízala cuando corresponda antes de ejecutar quick.
En quick se escribe interface, ip-address y port. Para guardar esos filtros en la configuración se utiliza set con el prefijo filter-, por ejemplo filter-interface. No mezcles ambas formas.
Cómo ver todas las opciones disponibles en tu RouterOS
La forma más fiable de conocer las opciones de tu versión es consultar la ayuda integrada. Escribe una de estas líneas, deja un espacio al final y pulsa Tab dos veces sin ejecutar la línea:
/tool sniffer
/tool sniffer quick
/tool sniffer set En RouterOS 7 también puedes utilizar F1 para obtener ayuda contextual. Después de escribir un argumento como ip-protocol=, el autocompletado permite explorar los valores admitidos. En RouterOS 6 la ayuda utiliza ?.
Tabla de referencia de filtros y ajustes
Esta tabla agrupa los parámetros para facilitar su consulta. La ayuda local determina cuáles existen en tu versión.
| Configuración con set | Equivalente en quick | Uso |
|---|---|---|
filter-interface | interface | Interfaz de captura. |
filter-ip-address | ip-address | IPv4 en cualquiera de los extremos. |
filter-src-ip-address / filter-dst-ip-address | src-ip-address / dst-ip-address | IPv4 de origen / destino. |
filter-ipv6-address | ipv6-address | Prefijo IPv6. |
filter-src-ipv6-address / filter-dst-ipv6-address | src-ipv6-address / dst-ipv6-address | IPv6 de origen / destino. |
filter-port | port | Puerto en cualquiera de los extremos. |
filter-src-port / filter-dst-port | src-port / dst-port | Puerto de origen / destino. |
filter-ip-protocol | ip-protocol | TCP, UDP, ICMP, etc. |
filter-mac-address | mac-address | MAC en cualquier extremo. |
filter-src-mac-address / filter-dst-mac-address | src-mac-address / dst-mac-address | MAC de origen / destino. |
filter-mac-protocol | mac-protocol | Protocolo de capa 2. |
filter-direction | direction | rx, tx o any. |
filter-vlan | vlan-id | Identificador VLAN. |
filter-cpu / filter-size | cpu / size | Núcleo / tamaño. |
filter-operator-between-entries | Consultar ayuda local | Combinar entradas de un mismo filtro. |
memory-limit / memory-scroll | — | Búfer de memoria y rotación. |
file-name / file-limit | — | Archivo y límite. |
only-headers | — | Guardar cabeceras. |
streaming-enabled / streaming-server / filter-stream | — | Transmisión TZSP y exclusión del propio flujo. |
streaming-port | — | Según versión; otras lo incluyen en streaming-server. |
show-frame o quick-show-frame | show-frame | Mostrar contenido; nombre según versión. |
quick-rows / max-packet-size | rows / — | Opciones adicionales según versión. |
| — | duration / proplist | Duración / columnas, si están disponibles. |
Los submenús packet, host, protocol y connection permiten explorar la captura almacenada. Los comandos principales son quick, start, stop, save, print y set.
Ejemplo práctico: capturar una IP, una interfaz y un puerto
Supongamos que una computadora con IP 192.168.10.50 no resuelve nombres. Su tráfico entra por ether2-LAN y queremos comprobar una consulta al DNS 1.1.1.1.
- Inicia esta captura en el MikroTik:
/tool sniffer quick interface=ether2-LAN ip-address=192.168.10.50/32 ip-protocol=udp port=53 direction=anyDesde esa computadora, abre una consola de Windows y genera una consulta:
nslookup example.com 1.1.1.1Este comando de Windows fuerza la consulta al DNS indicado. Hacer un ping desde el propio MikroTik no reproduce el recorrido del cliente.
El filtro reúne cuatro condiciones: la interfaz elegida, la IP del cliente, UDP y el puerto 53. ip-address y port contemplan origen o destino, de modo que podemos observar solicitudes y respuestas.
Para mirar solo solicitudes entrantes, usa:
/tool sniffer quick interface=ether2-LAN src-ip-address=192.168.10.50/32 ip-protocol=udp dst-port=53 direction=rxEsta segunda variante excluye las respuestas de forma intencional. Para revisar ambos sentidos vuelve al primer comando.
Cómo leer el resultado de Packet Sniffer de forma básica
La siguiente tabla es un ejemplo didáctico simplificado, no una captura real. RouterOS puede mostrar otras columnas o abreviar los nombres según el ancho de la terminal.
| INTERFACE | TIME | DIR | SRC-ADDRESS | DST-ADDRESS | PROTOCOL |
|---|---|---|---|---|---|
| ether2-LAN | 1.200 | ← | 192.168.10.50:53024 | 1.1.1.1:53 | ip:udp |
| ether2-LAN | 1.245 | → | 1.1.1.1:53 | 192.168.10.50:53024 | ip:udp |
- INTERFACE: punto donde se observó el paquete.
- TIME: segundos desde el inicio de la captura; no es la hora del día.
- DIR:
<-orxindica recepción y->otxtransmisión respecto de la interfaz del MikroTik. - SRC-ADDRESS y DST-ADDRESS: origen y destino. En
192.168.10.50:53024, lo que sigue a los dos puntos es el puerto. - PROTOCOL: protocolo observado. Otras columnas pueden mostrar tamaño en bytes, MAC, número de paquete o CPU.
En la primera fila el cliente envía tráfico hacia el puerto 53. En la segunda aparece tráfico de vuelta hacia su puerto temporal 53024. Eso es coherente con un intercambio DNS, pero la tabla por sí sola no demuestra que la resolución haya sido correcta: también podría tratarse de una respuesta de error.
La dirección siempre es relativa al MikroTik: en la LAN una consulta entra y su respuesta sale; en la WAN la consulta sale y la respuesta entra.
Cómo utilizar la captura para ir descartando el problema
La siguiente secuencia propone comprobaciones, no diagnósticos automáticos:
| Observación | Siguiente comprobación |
|---|---|
| No aparece la consulta en la LAN. | Confirmar IP, interfaz, filtros y que el cliente genere la prueba. Revisar su conexión y puerta de enlace. |
| La consulta entra en LAN; no se observa salir por la WAN esperada. | Revisar ruta, otra posible WAN, firewall, NAT y visibilidad de la captura. |
| Sale por WAN; no se observa respuesta. | Revisar retorno, proveedor, destino y otras interfaces. No atribuir todavía el fallo a un equipo concreto. |
| La respuesta entra en WAN; no se observa salir hacia el cliente. | Revisar firewall, seguimiento de conexiones, traducción inversa y ruta hacia la LAN. |
| Se observa intercambio en LAN. | Comprobar el resultado de nslookup y luego el servicio afectado. |
Comparar con la WAN sin perder el tráfico por NAT
Detén la captura anterior y repite la prueba observando el DNS remoto en la WAN:
/tool sniffer quick interface=ether1-WAN ip-address=1.1.1.1/32 ip-protocol=udp port=53 direction=anyEn una salida con src-nat o masquerade, la IP privada del cliente se sustituye por una IP de salida y también puede cambiar el puerto. Por eso filtrar 192.168.10.50 en la WAN podría no mostrar nada. El filtro hacia el DNS puede incluir consultas de otros clientes: genera una prueba controlada y compara tiempos.
Si existe una redirección DNS, un túnel o una política de salida, adapta el destino y la interfaz a ese recorrido.
Limitaciones que debes tener en cuenta
- Firewall: observar un paquete recibido no prueba que una regla lo haya aceptado.
- Hardware offloading: el tráfico conmutado directamente en hardware puede quedar fuera de la captura.
- FastPath y FastTrack: ejecutar el sniffer puede alterar la aceleración y el comportamiento del tráfico. Si el fallo desaparece durante la prueba, revisa esa relación.
- Bridge y puertos: observar varios puntos puede mostrar el mismo paquete más de una vez.
- Protocolo correcto: este ejemplo observa DNS por UDP; no incluye DNS por TCP ni DNS cifrado. ICMP no utiliza puertos TCP/UDP.
En producción, utiliza filtros y capturas breves, supervisa la CPU y detén la herramienta al terminar. Evita modificar reglas de firewall o desactivar aceleración sin haber identificado primero el recorrido.
Cómo guardar una captura para analizarla después
Cuando necesites conservar paquetes, termina primero la vista quick. Revisa los ajustes existentes con print, incluidos otros filtros, archivo y streaming, y ejecuta una captura corta:
/tool sniffer start interface=ether2-LAN ip-address=192.168.10.50/32 ip-protocol=udp port=53 direction=anyReproduce el problema y, a continuación, detén y guarda la captura:
/tool sniffer stop
/tool sniffer save file-name=diagnostico-dns.pcapDescárgala desde Files y ábrela en Wireshark. A partir de RouterOS 7.20 el contenido se guarda en PCAPNG, aunque el nombre termine en .pcap. Usa otro nombre si necesitas conservar una captura anterior y guarda pronto los paquetes que te interesen: el búfer es temporal y limitado.
Para revisar la lista almacenada desde la terminal:
/tool sniffer packet printComparte únicamente los datos necesarios para el diagnóstico: una captura puede contener información de los usuarios.
Preguntas frecuentes
¿Es mejor utilizar WinBox o la terminal?
Ambos permiten capturar tráfico. WinBox facilita explorar los campos; la terminal permite repetir y adaptar pruebas con rapidez. Para una asistencia remota, un comando con filtros suele ser muy práctico.
¿Ver paquetes significa que el servicio funciona?
No. Ver una solicitud confirma su presencia en el punto observado. Para evaluar el servicio debes revisar la respuesta y el resultado de la aplicación.
¿Qué hago si no aparece ningún paquete?
Confirma que estás reproduciendo el problema durante la captura. Revisa IP, interfaz, protocolo y puerto; después considera NAT, encapsulación y procesamiento por hardware.
Próximo paso: interpretar los paquetes para diagnosticar
Ya puedes comprobar dónde aparece una solicitud y seguir su recorrido básico. En una segunda entrada profundizaremos en consultas y respuestas DNS, banderas TCP, retransmisiones y capturas en Wireshark, para pasar de observar tráfico a interpretar una falla.
Publicar un comentario