How to Migrate from NGINX Ingress Controller to NGINX Gateway Fabric (Configmap)

[jinhee6930]

Hi, I’m planning to migrate from the NGINX Ingress Controller to NGINX Gateway Fabric.
When deploying the NGINX Ingress Controller, I previously used the following settings in the ConfigMap:

• allow-snippet-annotations: "true"
• keepalive-timeout: "600"
• ssl-redirect: "false"
• proxy-read-timeout: "600"
• proxy-send-timeout: "600"
• use-forwarded-headers: "true"

To apply equivalent behavior in NGINX Gateway Fabric, I believe the following approach makes sense:

1. allow-snippet-annotations: "true"
   Enable snippet filters when installing NGINX Gateway Fabric via Helm:

helm install ngf oci://ghcr.io/nginx/charts/nginx-gateway-fabric \
  --create-namespace -n nginx-gateway \
  --set nginxGateway.snippetsFilters.enable=true

2. keepalive-timeout: "600"
   Create a ClientSettingsPolicy and set targetRef to the Gateway.
   Any Routes attached to that Gateway should inherit these ClientSettingsPolicy settings.

spec.keepAlive.timeout = 600

3. ssl-redirect: "false"
   Simply avoid using spec.rules.filters.requestRedirect in the HTTPRoute.

4. proxy-read-timeout: "600" and proxy-send-timeout: "600"
   I’m not sure how to configure equivalents for these timeouts in NGINX Gateway Fabric.
   Are there defaults for these settings in nginx gateway fabric?

5. use-forwarded-headers: "true"
   This is the part I’m most curious about.
   I want to know how to replicate the NGINX Ingress Controller’s use-forwarded-headers: "true" behavior in NGINX Gateway Fabric.
   I need to be able to determine the client's IP through that setting.

I’d appreciate it if someone could confirm whether my understanding of items 1–3 is correct, and also explain how to handle items 4 and 5.

For reference, I know that ClientSettingsPolicy currently supports the following fields:

body.maxSize
body.timeout
keepAlive.requests
keepAlive.time
keepAlive.timeout

Please note that sentences may be strange due to the use of a translator.
Thank you.

[salonichf5]

Hey @jinhee6930, thanks for your interest in NGF!

You’re correct about options 1–3. For option 4–style directives, you can use the snippetsFilter API today to set proxy-read-timeout and proxy-send-timeout.

I’m not sure what your exact header-forwarding use case is, but you might be able to achieve what you want with the XForwardedFor mode.

[jsalgado78]

Hi,

I'm a similar issue to migrate use-forwarded-headers annotation because of it passes the incoming X-Forwarded-* headers to upstreams as is and there's no equivalent in Nginx Gateway Fabric. XForwardedFor mode appears to be for X-Forwarded-For header only.

There's no equivalent to proxy-read-timeout and proxy-send-timeout annotations, too.

These annotations are widely used in Nginx Ingress.

Thanks.

[jinhee6930]

Thank you for your response.
I think I found a solution.
After reading the links you shared, I’m planning to configure things as follows:

---

4. proxy-read-timeout: "600" and proxy-send-timeout: "600"
   I will create a SnippetsFilter and reference it in the HTTPRoute:

kubectl apply -f - <<EOF
apiVersion: gateway.nginx.org/v1alpha1
kind: SnippetsFilter
metadata:
  name: ngf-sf-proxy-timeout
spec:
  snippets:
    - context: http.server.location
      value: proxy_read_timeout 600s;
    - context: http.server.location
      value: proxy_send_timeout 600s;
EOF

The only downside is that I would prefer to apply this at the Gateway or GatewayClass level rather than on each HTTPRoute.
However, based on the documentation, it seems that SnippetsFilter can only be applied at the HTTPRoute (or GRPCRoute) level:

• “SnippetsFilter is a filter that allows inserting NGINX configuration into the generated NGINX config for HTTPRoute and GRPCRoute resources.”
• https://docs.nginx.com/nginx-gateway-fabric/reference/api/#gateway.nginx.org%2fv1alpha1.SnippetsFilter

---

5. use-forwarded-headers: "true"
   I plan to create an NginxProxy and attach it to the Gateway.
   Although I could modify the NginxProxy associated with the GatewayClass, I will only be using a single Gateway, so attaching a dedicated NginxProxy directly to the Gateway is simpler.

According to the documentation, an NginxProxy attached to a Gateway has higher precedence than one attached to a GatewayClass, and both configurations are merged:
https://docs.nginx.com/nginx-gateway-fabric/how-to/data-plane-configuration/#merging-semantics

Here is my configuration:

kubectl apply -f - <<EOF
apiVersion: gateway.nginx.org/v1alpha2
kind: NginxProxy
metadata:
  name: ngf-proxy-config-gateway
spec:
  config:
    rewriteClientIP:
      mode: XForwardedFor
      trustedAddresses:
      - type: CIDR
        value: "10.0.0.0/24"
EOF

---

6. Gateway and HTTPRoute in Different Namespaces
   I will be creating only a single Gateway, and multiple applications will share this Gateway.
   The Gateway and the applications are located in different namespaces.
   Each HTTPRoute will be created in the application's namespace.
   To allow these HTTPRoute resources to reference the Gateway in another namespace, I configured the Gateway listener as follows:

allowedRoutes:
  namespaces:
    from: ALL

With this configuration in place, do I still need to create a ReferenceGrant?

Thank you.

[jsalgado78]

Thank you very much.

I get this error creating snippets with same context:

The SnippetsFilter "ngf-sf-proxy-timeout" is invalid: spec.snippets: Invalid value: "array": Only one snippet allowed per context

I suppose I need to create two snippets for context http.server.location

Does XForwardedFor send X-Forwarded-Proto and X-Forwarded-Host http haders as is to pods ?
XForwardedFor appears to send X-Forwarded-For header as is but it not affect to X-Forwarded-Host and X-Forwarded-Proto