> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/knowledge-base/es/networking/firewall-connection-tracking-state.md).

# Estado de seguimiento de conexiones en las reglas de firewall

Cómo usar el campo Estado de seguimiento de conexiones en las reglas de firewall de VergeOS para bloquear nuevas conexiones entrantes sin cortar el tráfico de retorno para las conexiones salientes.

## Resumen

{% hint style="info" %}
**Puntos clave**

* Las reglas del firewall de VergeOS son con estado; el **Estado de seguimiento de conexiones** campo coincide con paquetes según el estado de conntrack.
* Delimite una **Descartar** regla al estado `nuevo` para bloquear conexiones entrantes no solicitadas sin descartar el tráfico de retorno.
* No añada su propia regla accept para el tráfico de retorno — la cadena generada ya acepta `establecido`/`relacionado` el tráfico.
  {% endhint %}

Las reglas del firewall de VergeOS son con estado. El **Estado de seguimiento de conexiones** campo en una regla de red coincide solo con los estados de conntrack seleccionados. Su uso más común es hacer que una **Descartar** regla bloquee *nuevo* las conexiones entrantes sin descartar también el *tráfico de retorno* de conexiones que el host protegido inicia por sí mismo.

## Requisitos previos

* Familiaridad con [las reglas de red de VergeOS](/run-the-platform/es/redes/network-rules.md).
* Un usuario con permiso para editar reglas de red.

## El campo Estado de seguimiento de conexiones

El campo está disponible en el formulario de edición de la regla de red. Déjelo en blanco para coincidir con cualquier estado.

**Valores permitidos:** `nuevo`, `establecido`, `relacionado`, `sin seguimiento`.

| Estado            | Significado                                                                                                  |
| ----------------- | ------------------------------------------------------------------------------------------------------------ |
| `nuevo`           | El primer paquete de una conexión — un intento de conexión no solicitado.                                    |
| `establecido`     | Paquetes que pertenecen a una conexión ya vista en ambas direcciones.                                        |
| `relacionado`     | Una nueva conexión que conntrack vincula a una existente (por ejemplo, canales de datos FTP y errores ICMP). |
| `sin seguimiento` | Paquetes excluidos explícitamente del seguimiento de conexiones.                                             |

El campo acepta varios estados separados por comas (`establecido,relacionado`) y negación con un prefijo `!=` (`!= new`).

{% hint style="info" %}
No existe la `inválido` opción. VergeOS ya descarta paquetes inválidos con una regla base del sistema (`ct state invalid drop`) cerca de la parte superior de cada cadena generada, por lo que no debe añadir una usted mismo.
{% endhint %}

## El problema: una regla de descarte que rompe el tráfico saliente

Una sola IP pública se usa a menudo tanto para servicios entrantes como para la dirección SNAT saliente de un inquilino o una VM detrás de ella. Una regla general **Descartar** en esa IP de destino bloquea el tráfico entrante no solicitado como se pretende — pero también descarta las respuestas al propio tráfico saliente del inquilino, porque esas respuestas llegan a la misma IP pública en estado `establecido`.

El síntoma: el inquilino no puede acceder a internet, y quitar la regla de denegación lo soluciona.

Quitar el descarte deja pasar las respuestas establecidas, pero también vuelve a abrir el acceso entrante no solicitado — exactamente lo que la regla fue creada para bloquear. No quite la regla; delimítela.

## La solución: delimitar el descarte a nuevas conexiones

1. Desde el panel de control de la red, haga clic en **Reglas** en el menú de la izquierda.
2. Seleccione la **Descartar** regla y haga clic en **Editar** en el menú de la izquierda.
3. En el **Estado de seguimiento de conexiones** campo, escriba `nuevo`.
4. Haga clic en **Enviar**.
5. Haga clic en **Aplicar reglas** en el menú de la izquierda para aplicar el cambio.

El descarte ahora solo coincide con conexiones entrantes nuevas y no solicitadas. El tráfico de retorno de las conexiones salientes está en estado `establecido`establecido,relacionado `ct state established,related accept`.

## Por qué no se necesita una regla accept para la ruta de retorno

VergeOS genera las cadenas de cada red `de entrada` y `de reenvío` con una `política de descarte` y una `ct state established,related accept` aceptación final `política de descarte` y `como última línea. nftables evalúa las reglas de arriba hacia abajo, y` aceptación `nuevo` son terminales: un descarte sin delimitar colocado por encima de esa aceptación final captura el tráfico de retorno antes de que llegue a la aceptación. Delimitar el descarte a

> **Modelo mental:** Bloquee `nuevo` para bloquear el tráfico entrante no solicitado. Deje que `establecido` y `relacionado` fluya para que cualquier cosa que inició el host protegido pueda terminar.

## Conviene saber

* El orden de las reglas importa. El `ct state established,related accept` es la última línea de la cadena generada; un descarte general por encima de ella sin estado configurado se traga el tráfico de retorno.
* El mismo alcance se aplica a cualquier regla, no solo a los descartes. Por ejemplo, delimite un **Aceptar** a `nuevo` para controlar qué lado puede iniciar conexiones.
* El `relacionado` el estado importa para protocolos con flujos secundarios rastreados por ayudantes (FTP, algunos VoIP, errores ICMP); el accept del sistema al final los cubre.

## Recursos adicionales

* [Reglas de red](/run-the-platform/es/redes/network-rules.md)

{% hint style="info" %}
**¿Necesita ayuda?**

Si tiene preguntas o problemas con este procedimiento, póngase en contacto con el equipo de soporte de VergeOS.
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.verge.io/knowledge-base/es/networking/firewall-connection-tracking-state.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.