Kassinipedia

Virtual Wire

Se lee en 7 min

Virtual Wire

Resumen

Virtual Wire (vwire) es el modo más sencillo de poner un firewall en una red existente: el firewall se comporta como un “cable inteligente” entre dos interfaces. No tiene IP en esas interfaces, no enruta, no aprende MAC ni participa en la red; solo recibe el tráfico por un lado, lo inspecciona con la Security Policy y los perfiles, y lo deja salir por el otro. Los equipos a ambos lados ni se enteran de que está ahí.
Es ideal para añadir seguridad sin rediseñar la red (sin cambiar IP, gateways ni VLAN). Cada vwire une exactamente dos interfaces, cada una en su zona de tipo Virtual Wire, y por eso se pueden escribir reglas por zona (por ejemplo vw-inside a vw-outside). También puede dejar pasar tráfico etiquetado con VLAN (según los Tag Allowed). Esta nota cubre la creación de un Virtual Wire, las reglas necesarias (incluido el sentido contrario para cosas como DHCP) y sus limitaciones.

Requisitos previos

  • Dos interfaces físicas libres, que no estén en uso (en el lab: ethernet1/4 y ethernet1/5) (ver Lab PCNSA (curso))
  • Zonas de tipo Virtual Wire (una por interfaz)
  • Conocer el sentido del tráfico y las reglas que necesitarás en ambas direcciones
  • Si el tráfico lleva VLAN tags: definir qué tags se permiten
  • Security Policy: aunque el vwire sea transparente, las reglas siguen aplicando (ver Security Policy Fundamentals)

Conceptos clave

ConceptoQué es
Interfaz Virtual WireInterfaz sin IP, pareada con otra
Objeto Virtual WireUne las dos interfaces; define Tag Allowed y Multicast Firewalling
Zona Virtual WireTipo de zona que contiene interfaces vwire
Tag AllowedVLAN tags que el vwire deja pasar (por defecto 0 = solo sin tag; admite tags, rangos y listas separados por comas, p. ej. 0,10-20; 0-4094 = todos)
Link State Pass ThroughSi un lado cae, el otro también se baja, para que los equipos detecten el fallo
graph LR
    A["Red / Router A"] --- I1["ethernet1/4<br/>zona vw-inside"]
    I1 -. "Virtual Wire" .- I2["ethernet1/5<br/>zona vw-outside"]
    I2 --- B["Red / Router B"]

Lo que un Virtual Wire no puede hacer

No tiene IP ni enruta, así que no aplica funciones de capa 3 propias del firewall en esas interfaces: no es servidor DHCP ni hace routing, ni se usa para VPN/GlobalProtect terminadas en la interfaz. Soporta NAT, pero con las limitaciones propias de no tener IP en la interfaz (ver el aviso de NAT más abajo).

Configuración (Ejemplo, Lab PCNSA)

1. Interfaces en modo Virtual Wire

  1. Network > Interfaces > Ethernet > ethernet1/4 > Interface Type Virtual Wire.
  2. Pestaña Config: Virtual Wire New Virtual Wire.
  3. En la ventana: Name vwire-1, Interface1 ethernet1/4, Interface2 ethernet1/5, Tag Allowed (vacío o 0 para sin tag; para trunks, el rango de VLAN), Multicast Firewalling (marca si quieres aplicar reglas a multicast), Link State Pass Through (opcional).
  4. OK.
  5. Security Zone: New Zone > Name vw-inside, Type Virtual Wire. OK.
  6. Repite con ethernet1/5: Interface Type Virtual Wire, Virtual Wire vwire-1, Security Zone New Zone > vw-outside (tipo Virtual Wire).
  7. Commit.
set network virtual-wire vwire-1 interface1 ethernet1/4 interface2 ethernet1/5
set zone vw-inside network virtual-wire ethernet1/4
set zone vw-outside network virtual-wire ethernet1/5
commit

Si un comando no coincide con tu versión, usa Tab o ?.

2. Reglas de Security Policy

El tráfico se evalúa por zona, como siempre. La Security Policy es stateful: el tráfico de respuesta de una sesión permitida no necesita regla inversa; solo las sesiones iniciadas desde el lado contrario (y casos como DHCP, cuyo Offer es un flujo nuevo) necesitan su propia regla.

  1. Policies > Security > Add > Name vw-in-to-out.
  2. Source Zone vw-inside, Destination Zone vw-outside, Application any (o las que necesites), Action Allow, Log at Session End.
  3. Commit.

Para tráfico que inicia el lado contrario, crea la regla inversa:

  1. Policies > Security > Add > Name vw-out-to-in.
  2. Source Zone vw-outside, Destination Zone vw-inside, y la Application que corresponda.
  3. Commit.

El caso de DHCP

Un cliente en un lado pide IP a un servidor en el otro lado. El DHCP Discover va en el sentido cliente → servidor, pero la DHCP Offer vuelve en el sentido contrario como un paquete broadcast/nuevo y, si no hay regla para ese sentido, se bloquea. Por eso, para DHCP a través de un vwire hace falta una regla con la aplicación dhcp en ambos sentidos.

3. Tráfico con VLAN tags

  1. Network > Virtual Wires > vwire-1 > Tag Allowed: por ejemplo 10,20 o un rango 10-20; 0 para tráfico sin etiqueta.
  2. Para aplicar políticas distintas por VLAN, crea subinterfaces Virtual Wire: edita la interfaz > Add Subinterface > Tag 10, Virtual Wire (vwire-1) y una zona propia. Cada subinterfaz de un lado debe tener su par con el mismo tag en el otro.
  3. Commit.
  1. Network > Virtual Wires > vwire-1 > marca Link State Pass Through.
  2. Si un lado pierde enlace, el firewall baja el otro, y los equipos detectan el fallo.
  3. Commit.

5. Un aviso sobre NAT

Se puede aplicar NAT en un Virtual Wire (reglas de NAT Policy entre las zonas Virtual Wire), pero como las interfaces no tienen IP, el firewall no responde a ARP por las direcciones traducidas. Las IP de origen o destino traducidas deben estar en la subred de la interfaz y el equipo vecino debe tener una ruta o una entrada ARP hacia ellas. Es un caso delicado: pruébalo en laboratorio y revisa la guía de tu versión.

Verificación

Comando o lugarQué debes verSi no lo ves
Network > Interfaces > EthernetAmbas interfaces en verde, tipo Virtual Wire, con su zonaSi está rojo, revisa el cable y el equipo del otro lado
Network > Virtual Wiresvwire-1 con Interface1 y Interface2Si falta una interfaz, edítalo
show interface ethernet1/4Estado, tipo vwire y zonaSi indica otro modo, corrige el Interface Type
Ping de extremo a extremo entre equipos a ambos ladosRespuestasSi no hay, revisa las reglas en ambos sentidos y los tags
Monitor > Logs > TrafficSesiones con zonas vw-inside y vw-outside y la reglaSi no aparece nada, no coincide ninguna regla o no pasa tráfico
show session all filter source <IP>La sesión con las interfaces de entrada y salidaSi no hay, el tráfico no llega al firewall
show counter global filter delta yes | match dropContadores de descartesÚtil si el tráfico se pierde sin logs
DHCP a través del vwire: Monitor > Logs > Traffic con aplicación dhcpSesiones permitidas en ambos sentidosSi solo ves el Discover, falta la regla inversa

Errores comunes

El tráfico no pasa por el Virtual Wire

  • Causa: no hay regla de Security Policy para esas zonas (aunque sea transparente, la política aplica), o el sentido contrario no tiene regla.
  • Revisa: Monitor > Logs > Traffic y las reglas por zona.
  • Solución: crea las reglas necesarias en cada sentido.

DHCP no funciona a través del vwire

  • Causa: falta la regla para la respuesta (Offer/ACK) en el sentido contrario.
  • Solución: permite la aplicación dhcp en ambos sentidos entre las dos zonas.

Los equipos pierden conectividad con VLAN

  • Causa: Tag Allowed no incluye esa VLAN, o falta la subinterfaz del otro lado.
  • Solución: añade el tag a Tag Allowed o crea subinterfaces par en ambos lados.

No puedo asignar una interfaz al vwire

  • Causa: ya está en uso en otro modo, o el objeto vwire ya tiene dos interfaces.
  • Solución: cambia el tipo de la interfaz; un vwire usa exactamente dos interfaces.

Un equipo no detecta que el enlace cayó

  • Causa: el vwire mantiene el enlace del otro lado activo.
  • Solución: activa Link State Pass Through.

El NAT en vwire no se comporta como esperaba

  • Causa: el firewall no tiene IP en las interfaces y no responde ARP por las direcciones traducidas.
  • Solución: usa direcciones traducidas dentro de la subred conectada, agrega rutas o ARP estático en el vecino, o cambia a Layer 3 si necesitas NAT con más facilidad (ver Source NAT).

Quiero VPN o administración en esa interfaz

El multicast (por ejemplo OSPF o routing de vecinos) no pasa

  • Causa: Multicast Firewalling está activado y no hay una regla Allow para ese multicast (con la opción desactivada el multicast cruza el vwire sin evaluar la Security Policy).
  • Solución: desactiva Multicast Firewalling en el objeto vwire, o déjalo activo y permite la aplicación correspondiente (por ejemplo ospf) en la Security Policy.

Vista Gráfica

Retroenlaces