Puente TAP virtual de pfSense: tres puntos donde una trama puede morir

Desactivas una regla en la interfaz LAN, la trama sigue desapareciendo y la conclusión es que pfSense ignora su propio cortafuegos. Lo que suele haber ocurrido es que la decisión la tomó otro propietario: el propio puente, la interfaz miembro o el conmutador virtual fuera del invitado. Cada uno tiene su propio control y su propio registro.

Conviene separar los tres límites siguientes antes de cambiar un ajuste, porque desactivar uno no compensa el otro.

Una trama, tres propietarios de política

Una trama de un cliente TAP entra por el dispositivo de túnel, cruza el puente de pfSense, sale por un miembro LAN y luego pasa por un conmutador virtual antes de llegar a cualquier sitio. Dentro del invitado, el filtrado puede ocurrir en el puente o en las interfaces miembro, y cuál está activa es una elección de configuración, no una propiedad fija. Fuera del invitado, el hipervisor decide si ese adaptador virtual puede transmitir tramas con una MAC de origen que no posee. Un descarte en cualquiera de esos puntos se ve idéntico desde el cliente.

Anota la ruta prevista antes de investigar: miembro de túnel, puente, miembro LAN, conmutador virtual, destino. Después pregunta qué propietario de esa ruta habría visto la trama.

Qué control de pfSense filtra

pfSense documenta dos sysctl para esto, uno para filtrar en los miembros del puente y otro para filtrar en el propio puente, y al menos uno de ellos debe permanecer activado. El filtrado a nivel de puente se aplica al tráfico que llega por los miembros del puente, así que es de entrada como orientación, no simétrico. Lee las reglas en la interfaz que filtra realmente, porque una regla puesta en un miembro sin papel de filtrado no hace absolutamente nada. La documentación de filtrado del puente explica la propiedad.

Una interfaz miembro sin dirección IP no tiene macro de dirección o subred propia, así que una regla escrita contra esa macro puede describir algo distinto de la LAN que pretendías. Usa objetos de red asignados deliberadamente en lugar de macros de conveniencia.

Un fragmento no es una trama

Las tramas Ethernet transportan paquetes IP, y un paquete IP puede ser un fragmento de un datagrama mayor, así que las dos palabras no son intercambiables. También hay un paquete interno dentro del túnel y un paquete de transporte externo fuera de él, y un fallo puede pertenecer a cualquiera de los dos. Un ping pequeño ejercita una ruta por esa pila y no demuestra nada sobre una transferencia grande. Compara el intercambio fallido en dos límites adyacentes y lee el motivo del descarte antes de culpar a una regla.

Si los fragmentos desaparecen, la respuesta es una corrección acotada o una investigación del tamaño de paquete, no una decisión de desactivar el filtrado por completo.

El hipervisor tiene su propia decisión de admisión

Un invitado que puentea tráfico para otras máquinas emite tramas cuyas MAC de origen no son las de su propio adaptador, y muchos conmutadores virtuales lo tratan como suplantación salvo que el grupo de puertos lo permita. Permitir esa transmisión y permitir que el adaptador reciba cada trama son controles separados, y activar ambos en todas partes es un cambio mucho mayor de lo que exige el problema. Determina qué tramas debe recibir y debe emitir el puente, y luego concede solo ese comportamiento en el límite que lo posee. Mantén el acceso a la consola antes de cambiar un puente gestionado de forma remota.

Restaurar la conectividad es la mitad de la prueba; la otra mitad es confirmar que un flujo que debería seguir bloqueado lo sigue estando.

Registra qué propietario filtró, qué control se cambió y qué dos flujos verificaste. Ese registro impide que el siguiente incidente empiece con la misma suposición de que pfSense se ignora a sí mismo.