Cloudflare abre su firewall a servidores con IP privada

Cloudflare deja de exigir una IP pública para proteger tu aplicación

Hasta hoy, poner el firewall de aplicaciones web (WAF) de Cloudflare delante de un servidor interno obligaba a una de tres cosas: exponer una IP pública, abrir un puerto en el firewall corporativo o ejecutar un conector adicional junto al origen. Cloudflare acaba de eliminar esas tres opciones con la disponibilidad general de Cloudflare services for private origins: apunta un registro DNS proxied a una IP privada y la plataforma llega al origen a través de la conexión de Cloudflare One que la empresa ya tiene montada.

Para un founder que construye productos con IA, el cambio es concreto: los backends de agentes, los servidores MCP y las APIs internas que nunca se diseñaron para mirar a Internet pueden ahora recibir tráfico externo con las mismas capas de protección que un sitio público, sin dejar de ser privados.

¿Qué cambió exactamente con la disponibilidad general?

La capacidad llevaba desde junio en beta cerrada, con acceso solicitado caso por caso al equipo de cuenta. Ahora se abre más allá de ese grupo.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

Lo que funciona sobre un origen privado, igual que sobre uno público:

WAF y reglas gestionadas
Gestión de bots
Limitación de tasa (rate limiting)
Caché
Reglas de transformación y reescritura
Workers

El origen conserva su IP privada y no hace falta ninguna excepción de entrada en el firewall. Y con Cloudflare WAN o Cloudflare Mesh tampoco hay que instalar software conector en el servidor de origen, lo que simplifica el mantenimiento y elimina un punto de fallo típico en infraestructuras pequeñas.

¿Cómo funciona el enrutamiento privado sin mover el tráfico a Internet?

El mecanismo es más simple de lo que sugiere la jerga. Se crea un registro A o AAAA proxied apuntando al origen. Para los rangos privados soportados, la opción Use private network routing se activa sola: direcciones RFC 1918, el rango CGNAT 100.64.0.0/10 (RFC 6598) y las direcciones IPv6 locales únicas fc00::/7 (RFC 4193). En esos rangos la función no se puede desactivar; un intento de hacerlo vía API devuelve error.

El resto del flujo no cambia: terminación TLS, WAF, reglas y caché siguen ejecutándose en la red de Cloudflare. Cuando el proxy detecta la marca de enrutamiento privado, en lugar de intentar conectar a la IP privada por Internet público, entrega la petición a la capa de red privada, que la encamina por la conectividad existente del cliente: IPsec, GRE, Cloudflare Tunnel, CNI o Cloudflare Mesh.

Para quien automatiza despliegues, el detalle práctico es que esto no es un producto nuevo que aprender, sino un atributo más en un registro DNS estándar de la API. La infraestructura como código existente solo necesita ese campo adicional.

¿Qué limitaciones conviene conocer antes de migrar?

No todo está cubierto. Argo Smart Routing y Aegis no están soportados, y los health checks de origen requieren Load Balancing. Cloudflare remite a su documentación de desarrollador para la lista completa de restricciones vigentes.

A esto se suman los requisitos previos, que en la práctica son el verdadero filtro: la cuenta necesita el entitlement de Private Origins, la conectividad de Cloudflare One ya desplegada y Unified Routing habilitado. Si conectas por Cloudflare WAN o Mesh, además hace falta una ruta de retorno para los rangos de origen de Cloudflare (100.64.0.0/12 en IPv4 y 2606:4700:cf1:5000::/64 en IPv6).

Cloudflare es explícito sobre el error más frecuente durante la beta: si las peticiones expiran y no llega nada al origen, lo primero que hay que revisar es la ruta de retorno. Una ruta faltante para el rango de origen fue el fallo de configuración más común.

¿Por qué el timing importa tanto para la seguridad de IA?

El contexto del sector explica por qué Cloudflare priorizó esto. En su llamada de resultados del segundo trimestre de 2026, la compañía señaló que más del 50% del tráfico de su red no era humano y que más del 80% de las principales empresas de IA ya son clientes, según recoge el análisis de The Globe and Mail. Ese dato es la base del argumento comercial: si la mayoría del tráfico lo generan agentes, los controles de identidad y acceso diseñados para personas se quedan cortos.

La competencia se mueve en la misma dirección. Zscaler cerró su año fiscal 2026 con más de 950 clientes de Zero Trust Everywhere, frente a más de 350 al cierre del año fiscal anterior, y Palo Alto Networks superó los US$100M de ARR con Prisma AIRS en cuatro trimestres desde su disponibilidad general, con más de 800 clientes al cierre de su año fiscal 2026, según el mismo análisis. El terreno de juego ya no es "quién protege mejor un portal web", sino quién protege el tráfico máquina a máquina.

En el frente financiero, Cloudflare reportó 4.698 clientes con más de US$100.000 de ingresos anuales al cierre del segundo trimestre de 2026, un 27% más interanual, y ese segmento representó el 73% de sus ingresos totales, de acuerdo con Yahoo Finance. El movimiento de orígenes privados es, leído así, una jugada para empujar a esos clientes grandes desde Application Services hacia el resto del portafolio.

Y hay una señal de hacia dónde va el producto: Cloudflare confirmó que trabaja en tráfico privado a privado, con beta cerrada prevista para principios de 2027. La idea es que un empleado abriendo wiki.company.internal reciba WAF, limitación de tasa y gestión de bots, y que el tráfico servicio a servicio entre nubes y centros de datos use los mismos controles aunque ninguna de las dos puntas toque Internet.

Qué significa esto para tu startup

Lo primero es ajustar expectativas sobre el acceso. Esto no es un plan self-serve: requiere el entitlement de Private Origins, que se activa pidiéndolo al equipo de cuenta. Si eres una startup pequeña sin contrato enterprise, hoy no puedes encenderlo desde el panel. Lo que sí puedes hacer es preparar el terreno.

Segundo, cambia la conversación de arquitectura. Durante años el atajo frente a un backend interno era exponerlo en un puerto alto "solo un rato" o meterlo detrás de una VPN que nadie audita. Si tu producto ya incluye agentes de IA o servidores MCP que hablan con sistemas internos, ahora existe una vía para publicarlos con WAF y límites de tasa delante, sin sumar superficie de ataque.

Acciones concretas que puedes ejecutar esta semana:

Documenta qué servicios internos necesitan exposición externa. Haz la lista de backends de agentes, MCP servers, APIs de partners y herramientas operativas. Para cada uno, anota si hoy está expuesto, detrás de VPN o simplemente inaccesible. Ese inventario es lo que vas a llevar a la conversación con tu proveedor de red, y también lo que te dirá cuánto riesgo estás cargando en silencio.
Revisa tu plan de rangos IP antes de tocar nada. Confirma que tus orígenes usan RFC 1918, CGNAT (100.64.0.0/10) o IPv6 local única. Si estás en esos rangos, la función se activa automáticamente y no podrás desactivarla, así que conviene validar el enrutamiento en un hostname de pruebas antes de mover producción.
Si ya operas Cloudflare One, prueba la ruta de retorno. El fallo más común de la beta fue no tener ruta para los rangos de origen de Cloudflare. Verifícalo en un entorno de staging para no descubrirlo con un incidente.
Evalúa el costo de oportunidad de tus conectores. Si hoy ejecutas software conector en cada origen, los modos WAN y Mesh eliminan esa dependencia. Para un equipo pequeño, menos agentes instalados es menos superficie que parchear.

Lo que todavía no resuelve

Conviene ser claro: la disponibilidad general cubre tráfico público hacia orígenes privados. El escenario inverso —que un agente en una red privada alcance una aplicación en otra red privada— sigue en desarrollo y apunta a beta cerrada a principios de 2027.

Tampoco es una solución de seguridad completa por sí sola. Un WAF delante de una API interna no arregla una autenticación mal implementada ni un endpoint sin autorización por objeto. La capa de Cloudflare filtra tráfico malicioso y aplica políticas; la lógica de permisos sigue siendo responsabilidad de tu producto.

Conclusión

La noticia es pequeña en titulares y grande en consecuencias arquitectónicas. Cloudflare cierra la brecha entre cómo se protege un sitio público y cómo se protege un servicio interno, y lo hace sin pedirte que muevas una IP ni que abras un puerto. En un año donde más de la mitad del tráfico de la red ya no lo genera un humano, la pregunta deja de ser si tus APIs internas necesitan WAF, y pasa a ser cuánto tardas en ponerlo delante.