[Bug] 2-networking-a-fedramp: the NVA return routes still omit the proxy-only subnets, so traffic from a regional managed load balancer's proxies cannot get replies from the internet

Abierto Apto para principiantes
  • ¿Algo no está bien?
#396 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
70/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
gcp, terraform
Área
infrastructure, networking

Línea de trabajo

Empieza con la entrada landing de local.routing_config en fast/stages-aw/2-networking-a-fedramp/nva.tf, que construye las rutas solo a partir de var.subnets, y compárala con subnets_proxy_only en branch-net-envs.tf y var.proxy_subnets en variables.tf. Está terminado cuando el CIDR proxy-only de cada entorno se incluye en las rutas de landing y la cloud-config del invitado NVA en modules/cloud-config-container/simple-nva/cloud-config.yaml lo recibe.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Bug Framework - FedRAMP High Framework - FedRAMP Moderate Gemini - Enterprise Level of Effort - Low Priority - Medium Scope - Blueprint Scope - Fast Scope - Module

Bug Description

PR #269 (closing #146) builds the NVAs' trusted-side return routes from every tenant subnet of every environment. The proxy-only subnet that branch-net-envs.tf creates in each environment spoke (subnets_proxy_only, CIDR from var.proxy_subnets[<env>], name proxy-<regions.primary>) is still not among them: the landing entry of local.routing_config in nva.tf reads var.subnets only (if s.tenant != null), and nva.tf never references var.proxy_subnets.

The spokes have their default routes deleted (delete_default_routes_on_create = true) and reach the internet through the default-route-nva route (0.0.0.0/0 → the NVA internal load balancer) and Cloud NAT on the DMZ VPC. A regional managed load balancer in a spoke — for example a regional internal Application Load Balancer whose backend is a regional internet NEG, which is how blueprints/gemini-enterprise reaches the Google-hosted Gemini Enterprise endpoint (gemini-stage-0/network.tf: an INTERNET_FQDN_PORT NEG for vertexaisearch.cloud.google.com) — originates its backend connections from the Envoy proxies in that spoke's proxy-only subnet. Those packets leave through the NVA and are masqueraded on the DMZ interface. The reply comes back to the NVA, is un-NATed to the proxy-only address, and — because the guest has no route for that range on the landing interface (simple-nva's cloud-config adds ip route add <cidr> via <eth1 gateway> only for the listed routes) — follows the VM's default route back out the untrusted interface. The connection hangs and times out; nothing errors at apply time, and DNS keeps resolving, so it reads as a firewall or DNS problem.

Environment and Deployment Context

  • Stellar Engine Version/Commit: v5.2.0 (82153050); unchanged on main @ e2396049 (2026-11-01). fast/stages-aw/2-networking-a-fedramp/nva.tf lines 28-37 (the landing routes), branch-net-envs.tf lines 114-119 (subnets_proxy_only; delete_default_routes_on_create at line 107), variables.tf lines 257-268 (proxy_subnets, one entry required per envs_folders key), modules/cloud-config-container/simple-nva/cloud-config.yaml lines 57-59 (guest routes only for the listed CIDRs).
  • Deployment Type:
    • US Region Restricted (e.g., Access Policy constraint)
    • FedRAMP Moderate
    • FedRAMP High
    • DoD IL4
    • DoD IL5
    • Stand-alone / Custom
  • FAST Stage (if applicable): 2-networking-a-fedramp

Steps to Reproduce

  1. Deploy Stages 0-2 with 2-networking-a-fedramp at v5.2.0, with proxy_subnets set for each environment (required by the variable's validation).
  2. In a spoke, deploy a regional managed load balancer whose backend is a regional internet NEG (for example gemini-stage-0 and gemini-stage-1 with the internal deployment type).
  3. Send a request to the load balancer from a client in the spoke.
  4. On an NVA: ip route get <an address in the proxy-only CIDR> shows the route via eth0 (the DMZ side), not eth1.

Expected Behavior

Every subnet whose egress is routed through the NVAs — tenant subnets and proxy-only subnets — gets a trusted-side return route, so replies to the load balancer's proxies are delivered.

Actual Behavior

Replies to the proxy-only range leave the NVA on the untrusted side; the load balancer's backend connections time out.

Relevant Logs and Errors

None at deploy time: the plan and apply succeed. The symptom is the request hanging at the load balancer.

Additional Context

  • Suggested fix — add each environment's proxy-only CIDR to the landing routes: 
    routes = flatten([
  for k, v in var.envs_folders : concat(
    [for s in try(var.subnets[lower(k)], []) :
      module.env-spoke-vpc[k].subnets["${s.region}/${s.name}"].ip_cidr_range
      if s.tenant != null],
    [var.proxy_subnets[k]]
  )
])
    (var.proxy_subnets is keyed by the envs_folders key itself, not its lower-cased form, and its validation already guarantees an entry for every environment.)
  • #146 reported the tenant-subnet half; it did not mention the proxy-only subnets, which is why #269 did not cover them.
Lenguaje dominante
HCL
Estrellas
61
Forks
28
Merge medio
1 d 17 h
PR fusionados (30 d)
75

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de google/stellar-engine

Todos los issues de google/stellar-engine

Issues similares

Más issues de DevOps

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.