SNI based routing failure

Hey! I’m trying to update a legacy setup where the team I am on inherited multiple rev-proxies and I’m trying to combine them into one. The issue I am having is even when I get a successful config to startup the haproxy service I can’t get it to work 100% of the time. It looks like it’s not following any of the rules and just defaulting to the default backend. We are now testing w/o a default backend and just trying to route on the incoming request url. The connections are coming from a metabase server using JDBC connection strings, and I’m thinking that maybe the SNI is not coming over correctly since it’s behind a load balancer in the cloud. I can’t configure the logs to even show anything helpful. Here is the config that we are using…

> global
>     log         127.0.0.1 local2
>     chroot      /var/lib/haproxy
>     pidfile     /var/run/haproxy.pid
>     user        haproxy
>     group       haproxy
>     daemon
> 
> defaults
>     mode                    tcp
>     option                  tcplog
>     log                     global
>     timeout queue           5m
>     timeout connect         10s
>     timeout client          5m
>     timeout server          5m
>     maxconn                 3000
> 
> # see /etc/resolv.conf nameserver address
> resolvers corpdns
>     nameserver resolver 10.10.0.2:53
> 
> frontend health_check
>     bind *:80
>     mode http
>     monitor-uri /health_check
> 
> frontend https
>     bind        *:443
>     mode        tcp
> 
>     tcp-request inspect-delay 5s
>     tcp-request content capture req.ssl_sni len 25
>     tcp-request content accept if { req_ssl_hello_type 1 }
> 
>     use_backend dbread_uat if { req.ssl_sni -i db-read-new.uat.fakeurl.com }
>     use_backend dbread_preprod if { req.ssl_sni -i db-read.preprod.fakeurl.com }
> 
> backend dbread_uat
>     mode tcp
>     server replica_uat db-replica.uat.fakeurl.com:5432 check resolvers corpdns
> 
> backend dbread_preprod
>     mode tcp
>     server replica_preprod db-replica.preprod.fakeurl.com:5432 check resolvers corpdns

You are on point, SNI based routing will not work when the client_hello does not contain the SNI field.

If you can’t use haproxy logging, you can verify externally by capture the SSL handshake (tcpdump, etc all) and checking the field in wireshark, or with tools like ssldump.

Yea, so the SNI wasn’t coming over from Metabase. We tried using different SSL methods and it just didn’t click. Thanks!