I would agree its a connection reuse issue, #1107 is probably a more relevant discussion to have.

As an experiment I tried a modified version of tcp_main.c with the connection lookup modified to not return an existing connection and the expected behaviour was observed.

Thinking the further the ideal solution from my point of view would be a pair of config values, one to enable a enhanced matching mechanism, and a complementary value list of ips which need to be outbound sni aware and takes the tls profile into account when a configured ip is matched as the destination. Unfortunately this would be non trivial as correct me if I'm wrong but the tls profile is attached after the connection is created so a chicken and egg problem? I agree this isnt vast majority use case territory but would be invaluable for offering hosted services and allows me to keep the rest of the architecture and network config the same. As surely an outbound connection with a different servername specified should be treated as distinct connections even if the destination is the same?

The issue I have with aliases is that I would swap the admin burden of adding sans to the ssl and doing a tls.reload to having to restart the service, and increase the number of open ports at the edge, basically its not scalable enough, I can just about cope with slow tls reload when you have more than one cert loaded (trivial load test with 30 certs took over 60 secs to reload) The whole impetus for trying to use sni with kamailio would be offer a scalable, automatable provisioning for direct routing customers, which doesn't have a restriction on number of sans defined on the cert (think simplicity of adding a vhost in nginx). Currently provisioning can be done live by expanding a cert, updating the dispatcher with new entries and reloading tls and dispatcher with kamcmd.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.