Allow nginx gateway to ignore lack of SNI

[mikkoc]

Similarly to #3977 but using ALB instead of NLB.

We terminate HTTPS at the ALB and then we must re-establish HTTPS (with a self-signed cert, but it does not matter since ALB does not validate it) on EC2 backend nodes, where NGINX Gateway Fabric is running.

ALB does not relay SNI information according to AWS support.

nginx does not like that and logs:

2025/12/31 15:18:24 [info] 26#26: *385 handshake rejected while SSL handshaking, client: 100.66.101.57, server: 0.0.0.0:443

Enabling debug logs, we can see that SSL server name: null:

2025/12/31 15:22:09 [debug] 26#26: accept on 0.0.0.0:443, ready: 0
2025/12/31 15:22:09 [debug] 26#26: posix_memalign: 0000FFFF90FB37D0:512 @16
2025/12/31 15:22:09 [debug] 26#26: *52 accept: 100.66.101.57:64254 fd:3
2025/12/31 15:22:09 [debug] 26#26: *52 event timer add: 3: 60000:1528613
2025/12/31 15:22:09 [debug] 26#26: *52 reusable connection: 1
2025/12/31 15:22:09 [debug] 26#26: *52 epoll add event: fd:3 op:1 ev:80002001
2025/12/31 15:22:09 [debug] 26#26: timer delta: 6275
2025/12/31 15:22:09 [debug] 26#26: worker cycle
2025/12/31 15:22:09 [debug] 26#26: epoll timer: 60000
2025/12/31 15:22:09 [debug] 26#26: epoll: fd:3 ev:0001 d:0000FFFF90F29390
2025/12/31 15:22:09 [debug] 26#26: *52 http check ssl handshake
2025/12/31 15:22:09 [debug] 26#26: *52 http recv(): 1
2025/12/31 15:22:09 [debug] 26#26: *52 https ssl handshake: 0x16
2025/12/31 15:22:09 [debug] 26#26: *52 tcp_nodelay
2025/12/31 15:22:09 [debug] 26#26: *52 reusable connection: 0
2025/12/31 15:22:09 [debug] 26#26: *52 SSL server name: null
2025/12/31 15:22:09 [debug] 26#26: *52 SSL_do_handshake: -1
2025/12/31 15:22:09 [debug] 26#26: *52 SSL_get_error: 1
2025/12/31 15:22:09 [info] 26#26: *52 handshake rejected while SSL handshaking, client: 100.66.101.57, server: 0.0.0.0:443
2025/12/31 15:22:09 [debug] 26#26: *52 close http connection: 3
2025/12/31 15:22:09 [debug] 26#26: *52 event timer del: 3: 1528613
2025/12/31 15:22:09 [debug] 26#26: *52 reusable connection: 0
2025/12/31 15:22:09 [debug] 26#26: *52 free: 0000FFFF90FB37D0, unused: 112
2025/12/31 15:22:09 [debug] 26#26: timer delta: 1
2025/12/31 15:22:09 [debug] 26#26: worker cycle
2025/12/31 15:22:09 [debug] 26#26: epoll timer: -1

I have been down the rabbit hole with GPT to make it work, but was unable to.

Is there any chance nginx could ignore the lack of SNI? This works just fine (by default) with ingress-nginx but we need to migrate away from it.

Below our Helm values:

# Controller configuration
controller:
  replicaCount: 1

# Service exposure for the NGF data plane
nginx:
  # Accept backend TLS even if SNI doesn't match Host header (ALB backends often lack SNI)
  config:
    disableSNIHostValidation: true
    logging:
      errorLevel: debug
  debug: true
  service:
    type: NodePort
    nodePorts:
      - port: 31335
        listenerPort: 443
      - port: 31334
        listenerPort: 80


# Enable NGF SnippetsFilters (required for ExtensionRef SnippetsFilter)
nginxGateway:
  snippetsFilters:
    enable: true
  config:
    logging:
      level: debug

# Create a minimal Gateway so NGF provisions the data plane
# and the NodePort Service that matches the listener.
gateways:
  - name: ngf-gateway
    namespace: nginx-gateway
    spec:
      gatewayClassName: nginx
      listeners:
        - name: https
          port: 443
          protocol: HTTPS
          tls:
            mode: Terminate
            certificateRefs:
              - name: ngf-tls
                kind: Secret
                group: ""
          allowedRoutes:
            namespaces:
              from: All
        - name: http
          port: 80
          protocol: HTTP
          allowedRoutes:
            namespaces:
              from: All

[sjberman]

So ALB doesn't send the original hostname in the request? Does it send any hostname?

All of the server blocks are defined based on the hostnames specified in either the Gateway or the Routes, and those are set in the server_name directive. If a request comes in without a server name (or a mismatched server name), then nginx wouldn't know where that request needs to go, which is why it gets sent to the default_server, where it's ultimately rejected for not matching any of the server names that are configured.

[sjberman]

There's currently no defined way to do this.

When you say "everything works fine", what happens? There are no locations defined in the default server, so where would traffic be routed to? Paths defined in Routes will always be configured in servers that have server names defined.

If no default server exists, then the request is going to be sent to the first server that matches the request port. Which is a risk if you have multiple hostnames on that port, there's a chance it'll get sent to the wrong one. But if you only have a single hostname, then that may not be an issue.

[mikkoc]

I get a 404, which means the ALB was able to get a response from nginx - so that is what I meant with "everything works fine". Then I can go on to add variousHTTPRoutes, etc..

But until I hack the config as explained above, all I get is 502s which indicate the ALB is unable to establish a connection to nginx.

So I guess if we have to summarise the issue, it would be:
how to pass a TLS certificate and ssl_reject_handshake off for the default_server

using Helm values.

For completeness, here's the HTTPRoute I deploy:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: httpbin-nginx
  namespace: echo
spec:
  parentRefs:
  - name: ngf-gateway
    namespace: nginx-gateway
    sectionName: https
  hostnames:
  - ngf.testing.domain.com
  rules:
    - matches:
      - path:
          type: PathPrefix
          value: /
      backendRefs:
      - name: httpbin
        namespace: echo
        port: 80

[sjberman]

This would be a much more significant change than just helm values. Simply allowing the default server to accept the request isn't going to solve anything. Routes do not and cannot attach to the default server, so no routing can happen from there. The hostnames defined in Gateway listeners and Routes are the basis for how the nginx servers are configured and routing decisions can be made. The entire configuration is built around this structure, and it follows the Gateway API specification. Attaching routes to the default server would not only require an overhaul of our controller, it wouldn't meet the specification.

The easier solution would be to get rid of the default server altogether, though you then run the risk that I mentioned above. There may be other risks I'm not yet aware of.

I would like to spend some time figuring out a better solution if one exists, since this problem with ALB is a new one to me. If there was any way to configure ALB to send the server name, that would be ideal. But if that's impossible, then this would take some time to figure out a solution that doesn't break things.

[mikkoc]

According to AWS Support, there's already an open feature request to configure the ALB to relay SNI information, but of course there's no ETA :)

[sjberman]

Ok reading back through and testing this out, the reason you're getting a 404 is because the default server has no locations configured. It's not that it's hitting the 404 response from the other server with the root location defined (which is what I originally had thought in my original reply that I've since deleted).

[shaun-nx]

Hi @mikkoc

You asked in your first post if "there any chance nginx could ignore the lack of SNI?"
You mentioned that "this works just fine (by default) with ingress-nginx"

Could you show us the configuration you used for ingress-nginx that allowed this to work? (i.e. the Ingress YAML and generated NGINX config)
This might give us a lead into how to accomplish this use case.

[sjberman]

So it looks like all of the configuration is just duplicated between the default server and the specific hostname server. Seems to defeat the purpose of the Ingress hostname rule if the hostname ultimately isn't required.

What if you have multiple rules with different hostnames and paths on the same port?

[mikkoc]

We have about 50 Ingress objects to cover about 10-12 different hostnames and a multitude of different paths (APIs). The ingress-nginx port is always the same:

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/component: controller
  ports:
    - port: 443
      name: https
      nodePort: 31338

[sjberman]

And does the default server include locations and configurations for all of those paths?

[sjberman]

I also notice that your custom config like client_header_buffer_size isn't going to be honored if SNI isn't provided, because the default server doesn't configure this. This is inherently the problem with this structure. The configuration for the hostname can't be enforced if the traffic doesn't flow to that server.

[sjberman]

If you have an Ingress configuration like:

https://foo.com/api should proxy to foo-backend, and also have nginx directives x,y,z (timeouts or headers, etc)
https://bar.com/api should proxy to bar-backend, and also have nginx directives a,b,c (timeouts or headers, etc)

then without SNI, I don't see how this would work. The default server would accept all traffic, and the specific settings for each hostname would not be honored.

[sjberman]

Reviving this thread after thinking about things more and gaining a better understanding of how things work (and understanding that I was probably on the wrong path thinking about the Host header).

The Host header is probably still set, it's just SNI that's not set (I'm assuming). If that's the case, then adding a default cert/key to the default server should actually solve this problem. The request without SNI would initially hit that server and be terminated, but then nginx would use the Host header to route to the proper server block for that hostname.

I've created #4836 to track this work.

[sjberman]

This issue should now be fixed in our main branch (edge release) and will be included in our 2.5 release.

This doc snippet (currently not in our official docs until the 2.5 release) explains how to set things up properly to get non-SNI traffic working.

[SebastienTolron]

Hey @sjberman

Thanks for the great job !

Is it already implemented in the edge release ?

I did :

apiVersion: gateway.nginx.org/v1alpha2
kind: NginxProxy
metadata:
  name: infrastructure-proxy-settings
  namespace: routing
spec:
  disableSNIHostValidation: true

In my gateway :

spec:
  gatewayClassName: nginx
  infrastructure:
    parametersRef:
      group: gateway.nginx.org
      kind: NginxProxy
      name:  infrastructure-proxy-settings

But seems my default server still does not handle ssl handshake

js_preload_object matches from /etc/nginx/conf.d/matches.json;server {
    listen 443 ssl default_server;
    listen [::]:443 ssl default_server;
    ssl_reject_handshake on;
}

Versions :
ghcr.io/nginx/nginx-gateway-fabric:edge

And I applied 1.5 CRD

Did I miss something ?

Thanks :)

[sjberman]

Yes, this exists in the edge release. You need to ensure that you have a listener with an empty hostname defined, and your HTTPRoute attaches to that. That way the empty hostname acts as the default entrypoint.

This doc snippet describes the setup.

[SebastienTolron]

Wow thanks for the fast answer !

Yep I saw the doc snippet , but I missed the part with the empty listener. My bad !!

Works like a charm !

Thanks a lot for your support

you rock ! <3

[sjberman]

Glad it's working!