Firewall → Settings → Advanced → Disable reply-to on WAN rules → marcar → Save → Apply.

Síntoma: un port-forward o una regla WAN responde desde cualquier IP de internet, pero desde un equipo que vive en la misma subred que la WAN del firewall todo da timeout (SSH, HTTPS, incluso ping), aunque la regla diga from any.

Con una sola WAN es seguro: el firewall deja de forzar el regreso por el gateway y vuelve a usar su tabla de rutas.

El escenario

1
2
3
4
5
6
7
8

                203.0.113.0/24  (mismo segmento L2)
   ┌────────────────────┬────────────────────┬────────────────────┐
   │                    │                    │                    │
 gateway             fw01 (OPNsense)      vecino               internet
 203.0.113.1         WAN 203.0.113.40     203.0.113.50         (vía gateway)
                        │ rdr :22 → 192.168.1.10
                        ▼
                     servidor LAN

• Desde internet: ssh -p 22 203.0.113.40 entra al servidor de la LAN. Bien.
• Desde vecino (203.0.113.50): timeout en todos los puertos.

Qué hace reply-to

OPNsense genera las reglas de las interfaces tipo WAN (las que tienen gateway) con reply-to apuntando a ese gateway:

1

pfctl -sr | grep reply-to

1

pass in quick on vtnet0 reply-to (vtnet0 203.0.113.1) inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

reply-to es una opción de pf. Cuando un paquete entra y crea un estado, pf guarda en ese estado que todas las respuestas salgan por vtnet0 hacia 203.0.113.1. Esas respuestas no pasan por la tabla de rutas: pf decide el siguiente salto por su cuenta.

Existe por multi-WAN. Si tienes dos proveedores y un cliente entra por la WAN2, la respuesta tiene que salir por la WAN2. Si sale por la ruta por defecto (WAN1), lleva una IP de origen que el proveedor 1 no reconoce y se pierde. reply-to garantiza el regreso simétrico sin tener que pensar en rutas.

Por qué rompe a los vecinos

Para un cliente en internet, «responder al gateway» es justo lo que haría la tabla de rutas, así que no se nota nada.

Para el vecino es distinto. Su IP (203.0.113.50) está en una red conectada del firewall. Sin reply-to, el firewall resolvería su MAC por ARP y le respondería directo. Con reply-to, el SYN-ACK sale con la MAC del gateway como destino:

1
2

# en el OPNsense (shell csh: envuelve en sh -c)
sh -c "tcpdump -lnei vtnet0 host 203.0.113.50 and tcp port 22"

1
2

<mac-vecino> > <mac-fw01>          203.0.113.50.49612 > 203.0.113.40.22: Flags [S]    ← llega directo
<mac-fw01>   > 00:00:5e:00:01:<vrid> 203.0.113.40.22 > 203.0.113.50.49612: Flags [S.]   ← sale al gateway

(00:00:5e:00:01:xx es la MAC virtual de VRRP: el gateway era un par redundante.)

A partir de ahí depende del gateway. Para él, el paquete entra por la misma interfaz por la que tendría que salir, y si tiene un filtro con estado ve un SYN-ACK de una conexión cuyo SYN nunca vio. En el lab, el gateway simplemente no lo devolvía al segmento. En el vecino sólo se ven SYN reintentándose y ningún [S.].

La huella en el firewall es un estado a medias:

1

pfctl -ss | grep 203.0.113.50

1

all tcp 192.168.1.10:22 (203.0.113.40:22) <- 203.0.113.50:57792   SYN_SENT:ESTABLISHED

El servidor ya respondió (ESTABLISHED) y el cliente sigue esperando (SYN_SENT): la respuesta se pierde de regreso, no a la ida. El filtro no está bloqueando nada.

Qué cambia el fix

Con Disable reply-to on WAN rules activado, OPNsense regenera las reglas sin reply-to:

1

pass in quick on vtnet0 inet proto tcp from any to 192.168.1.10 port = ssh flags S/SA keep state

El estado ya no fija el siguiente salto, así que las respuestas pasan por la tabla de rutas normal:

La última fila es el costo. Con multi-WAN no lo desactives global. En vez de eso, quita el reply-to sólo en la regla del port-forward afectado: en la regla, Advanced → reply-to. Revisa las opciones que ofrece tu versión.

Verificar

1
2
3

# en el OPNsense
sh -c "pfctl -sr | grep -c reply-to; grep -n disablereplyto /conf/config.xml"
# esperado: 0  y  <disablereplyto>yes</disablereplyto>

1
2

# desde el vecino
nc -z -w5 203.0.113.40 22 && echo abierto

Trampas

• «Disable force gateway» no es esto. Está en la misma pantalla y tiene un nombre parecido, pero sólo afecta el tráfico que origina el propio firewall (DNS, NTP, actualizaciones). No toca las respuestas a tráfico entrante.
• Una ruta estática en el gateway no ayuda. El gateway ya tiene la subred como conectada; el problema es que no regresa el paquete al mismo segmento, no que no sepa llegar.
• Shell csh. Por SSH, OPNsense entra a csh y cosas como 2>/dev/null fallan con Ambiguous output redirect. Usa sh -c "..." o ssh root@fw01 sh <<'EOF'.
• Revisa todos los puertos, no uno. Si falla sólo un puerto es otro problema (regla, NAT, servicio). Si fallan todos, incluido ping, y sólo desde la misma subred, sospecha de reply-to.

Ver también

• Documentación de OPNsense, configuración del firewall: https://docs.opnsense.org/manual/firewall_settings.html
• pf.conf(5), opciones route-to / reply-to: https://man.freebsd.org/cgi/man.cgi?query=pf.conf

1
2
3
4
5
6
7
8
9

CLUSTER=my-cluster; REGION=us-central1; NETWORK=my-vpc
MASTER_CIDR=$(gcloud container clusters describe $CLUSTER --region $REGION \
  --format='value(privateClusterConfig.masterIpv4CidrBlock)')
NODE_TAG=$(gcloud compute firewall-rules list --filter="name~^gke-$CLUSTER" \
  --format='value(targetTags.list())' | head -1)

gcloud compute firewall-rules create gke-$CLUSTER-master-to-vault-injector \
  --network=$NETWORK --direction=INGRESS --action=ALLOW \
  --source-ranges=$MASTER_CIDR --target-tags=$NODE_TAG --rules=tcp:8080

Borra un pod anotado y comprueba que el injector recibe la llamada:

1
2
3
4
5

kubectl -n app delete pod -l app=api
kubectl -n vault logs deploy/vault-agent-injector | grep mutate
# [INFO]  handler: Request received: Method=POST URL=/mutate?timeout=30s
kubectl -n app get pod -l app=api -o jsonpath='{.items[0].spec.initContainers[*].name} {.items[0].spec.containers[*].name}{"\n"}'
# vault-agent-init api vault-agent

El síntoma

• El pod lleva vault.hashicorp.com/agent-inject: "true" y el resto de anotaciones, pero arranca solo con el contenedor de la aplicación: ni vault-agent-init ni vault-agent.
• Crear el pod tarda unos 30 segundos más de lo normal.
• kubectl get events no dice nada del webhook. En los logs del injector no hay ni una línea de Request received.
• En otros clústeres (zonales públicos, kind, k3s) el mismo chart y las mismas anotaciones funcionan.

Por qué

En un clúster privado de GKE el control plane vive en una VPC de Google y llega a tus nodos a través de la regla de firewall que GKE crea sola (gke-<cluster>-<hash>-master). Esa regla solo permite TCP 443 y 10250 desde el rango del control plane hacia los nodos. Todo lo demás está cerrado.

Un webhook de admisión no pasa por el Service como lo haría un cliente normal: el API server resuelve el Service a sus endpoints y conecta directamente con la IP del pod en el targetPort. El Service del injector (vault-agent-injector-svc) publica el 443, pero el pod escucha en el 8080 (injector.port del chart), así que la conexión real es al 8080 y el firewall la descarta.

Lo que pasa después lo explican dos valores por defecto del chart de Vault:

De ahí los 30 segundos de retraso y el pod sin sidecar y sin ningún mensaje. Con failurePolicy: Fail habrías visto failed calling webhook "vault.hashicorp.com": … context deadline exceeded en los eventos del ReplicaSet, que al menos apunta al sitio correcto.

No es solo Vault

Cualquier webhook de admisión, conversión de CRDs o API agregada que escuche en un puerto que no sea 443 o 10250 falla igual en GKE privado: el operador de OpenTelemetry (9443), Kyverno (9443), Gatekeeper (8443)… cert-manager escucha en el 10250 precisamente para no necesitar esta regla. La documentación de GKE lo lista como requisito de “admission webhooks, aggregated API servers, webhook conversion”: una regla por puerto, desde masterIpv4CidrBlock hacia los tags de los nodos.

Si el clúster está en Terraform, deja la regla junto al clúster para que no se pierda al recrearlo:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

resource "google_compute_firewall" "master_to_vault_injector" {
  name          = "gke-${google_container_cluster.main.name}-master-to-vault-injector"
  network       = google_compute_network.main.name
  direction     = "INGRESS"
  source_ranges = [google_container_cluster.main.private_cluster_config[0].master_ipv4_cidr_block]
  target_tags   = ["gke-${google_container_cluster.main.name}"]   # el tag que usan tus node pools
  allow {
    protocol = "tcp"
    ports    = ["8080"]
  }
}

Trampas

• El tag equivocado: los nodos llevan gke-<cluster>-<hash>-node; cópialo de las reglas gke-<cluster>-* existentes en vez de escribirlo a mano. Con varios node pools, comprueba que todos tengan el tag.
• El rango del control plane cambia si recreas el clúster; una regla escrita a mano con el CIDR viejo deja de servir sin avisar.
• failurePolicy: Fail hace visible el fallo, pero mientras el webhook esté caído no se crea ningún pod en los namespaces que casen con el namespaceSelector; el chart excluye al propio injector, pero no a Vault si comparten namespace y etiquetas. Úsalo con replicas: 2.
• El injector sí recibe la petición y sigue sin sidecar: entonces ya no es red. Mira los logs de vault-agent-init: permission denied es el rol de Kubernetes auth (bound_service_account_names, bound_service_account_namespaces) o la política; connection refused es vault.hashicorp.com/service o la dirección de Vault.
• Un solo puerto por regla no escala: si acumulas webhooks, una regla con --rules=tcp:8080,8443,9443 desde el control plane es más fácil de mantener que cinco.

Referencias: vault-k8s #46, vault-k8s #32 y reglas de firewall en clústeres privados en la documentación de GKE.

Ver también

• cert-manager: el reto HTTP-01 devuelve 308 — otro componente que “no hace nada” hasta que miras el sitio correcto.
• GitHub Actions → Google Cloud sin llaves — para desplegar en ese GKE sin llaves JSON.