Punto de partida

He estado evaluando una idea para conectar varios sitios usando “solo Internet”, en lugar de los servicios MPLS tradicionales. De las varias opciones que tengo en mente, una es tener un OPNSense como punto de peering para cada LAN. Todos estarían conectados usando Zerotier SDN en L3 con “managed routes”.

Identifiqué un límite de 128 rutas en la opción “managed routes”, así que probablemente necesitaré correr un route reflector BGP en la configuración final, pero para la PoC inicial las managed routes sirven.

Esquema básico de la PoC

Este es un diagrama básico de lo que se probó. Cada endpoint OPNSense correría el cliente zerotier y haría el forwarding. La información de rutas la enviaría el controller.

esquema de red
Imagen 1 - Esquema de red de la PoC

Rutas tal como se definieron en el controller:

10.1.0.0/24 via 172.16.1.10

10.2.0.0/24 via 172.16.1.20

El problema

Durante mis pruebas vi que la conexión entre sitios (LAN del lado A vs LAN del lado B) es muy intermitente, con 30-60% de pérdida de paquetes.

Análisis del problema

Creé un pequeño script para OPNsense que revisa continuamente el estado del peer.

Para tu referencia, el archivo se crea así:

mkdir ~/bin
touch ~/bin/check-peer.csh
chmod +x ~/bin/check-peer.csh
vi ~/bin/check-peer.csh

Contenido a insertar:

#!/bin/csh

# * Sat Dec  9 16:02:33 -03 2023 - ciro.iriarte (at) gmail.com
# - Basic script to review peer underlay IP

if  ($# != "1") then
        echo "usage:"
        echo "  $0 <peer id>"
        exit
endif

while ( 1 )
  zerotier-cli peers | grep $1
  sleep 3
end

Ejemplo de ejecución:

root@opnsense-A:~/bin # check-peer.sh 0f02bd4XXX
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   252      413      <public IP>/25545
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      <public IP>/25545

Lo que encontré fue que cuando el cliente no tenía respuesta al ICMP echo request (el comando ping), la salida mostraba un cambio en la IP del peer a la IP interna de la LAN.

root@opnsense-B:~/bin # check-peer.sh 0f02bd4XXX
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   252      413      <public IP>/25545
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      <public IP>/25545
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      10.1.0.1/25645 
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      10.1.0.1/25645
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      10.1.0.1/25645
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      10.1.0.1/25645
0f02bd4XXX 1.12.2 LEAF       0 DIRECT   347      265      <public IP>/25545

En el pasado vi, a través de logs del firewall y capturas de tcpdump, que Zerotier es muy promiscuo/agresivo e intenta llegar a los peers usando CUALQUIER interfaz disponible. Entiendo que esto es parte de la experiencia “just works” que idearon, pero es raro que intente llegar a un peer del underlay a través de la red overlay (por medio de L3 hacia una red remota en este caso).

Esperaría que Zerotier evite usar las interfaces zt* por defecto.

Reportes similares

Andy Liebman

Andy Liebman reportó el mismo escenario en el foro, pero lamentablemente nadie respondió y para cuando llegué al post ya estaba cerrado y no se podían agregar más comentarios.

u/legacyproblems en Reddit

No necesariamente el mismo escenario, pero es similar. Esta persona bloqueó los flujos no deseados con reglas de firewall:

I ran into a similar issue a while back where I have some devices acting as gateways onto my ZeroTier LAN and > devices on the real LANs these gateways were connected to would tunnel through the same ZeroTier LAN via the > gateways…

Ended up adding a rule to block 9993 UDP on my ZeroTier LAN via the ZeroTier network rules engine.

referencia

Blacklists

Recuerdo haber visto reportes similares que se resolvieron usando blacklists, pero ahora no logro encontrar esos posts para agregar los enlaces.

Prefiero no ir por ese camino porque en los firewalls agregar interfaces nuevas es bastante frecuente y lo más probable es que me olvide de poner en la blacklist las interfaces nuevas que no deberían usarse para tráfico del underlay.

Para mi caso de uso un whitelist tendría mucho más sentido, decirle a Zerotier “usa las interfaces WAN1 y WAN2 y nada más”, pero lamentablemente eso no parece estar soportado.

La solución

Descubrí que usar la nueva implementación de multipath parece imitar la lógica de whitelist que busco. Lo encontré por accidente: la IP privada del peer solo se veía en el sitio que no tiene multipath configurado.

El sitio A tiene dos interfaces WAN. En el pasado vi un comportamiento de navegación realmente raro en OPNSense con un grupo de gateways activo/activo, lo que me llevó a volver a grupos de failover. En este caso, pensaría que Zerotier podría hacer maravillas en escenarios activo/activo, pero por simplicidad mantuve la configuración activo/standby también para Zerotier.

local.conf se vería así:

{
  "settings": {
    "defaultBondingPolicy": "rapid-active-backup",
    "policies": {
      "rapid-active-backup": {
        "basePolicy": "active-backup",
        "failoverInterval": 1000,
        "links":
        {
          "ix0":
          {
            "ipvPref": 46,
            "failoverTo": "ix1"
          },
          "ix1":
          {
            "ipvPref": 46,
            "failoverTo": "ix0"
          }
        }
      }
    }
  }
}

El sitio B tiene una sola interfaz WAN; conceptualmente multipath no tiene sentido en este escenario, pero igual resuelve mi problema de “intentar llegar a la LAN remota a través de un peer en la LAN remota”.

local.conf se vería así:

{
  "settings": {
    "defaultBondingPolicy": "rapid-active-backup",
    "policies": {
      "rapid-active-backup": {
        "basePolicy": "active-backup",
        "failoverInterval": 1000,
        "links":
        {
          "igb1":
          {
            "ipvPref": 46
          }
        }
      }
    }
  }
}

Todavía veo una entrada esporádica con la IP de LAN del peer durante mis pruebas, pero los clientes reportan 0% de paquetes perdidos en una prueba ICMP de site a site (¿ping?/¡pong!).

Actualizaré el post si algo cambia.