allow wildcard when using sni

[KEZHwMlXV1vFzs6QvY8v5WjX5]

Currently it looks like I cannot use *.example.net as src in a route

route add myservice *.example.net https://10.1.1.1:30011 opts "proto=tcp+sni tlsskipverify=true"

curl https://fubar.example.net results in -> 018/09/12 08:24:37 [WARN] No route for fubar.example.net

Can we get this?

[aaronhurt]

The syntax in your route doesn't match. To use SNI routing of a request you want to setup a TCP listener using the proxy.addr directive in your configuration file with proto=tcp+sni. The route added will then just have a standard source and destination. To send to an HTTPs backend you will want to have proto=https on your route and optionally tlsskipverify=true if the backend cert cannot be validated.

[KEZHwMlXV1vFzs6QvY8v5WjX5]

yes proxy.addr=:443;proto=tcp+sni was set in the fabio.properties. And during startup fabio also states it's using tcp+sni on port 443.

What do you mean by standard source and destination?

[aaronhurt]

I mean you shouldn't need proto=tcp+sni or any options on the route to get SNI routing. If the backend is HTTPs then you will need proto=https and optionally tlsskipverify=true. You should not need any other options.

[KEZHwMlXV1vFzs6QvY8v5WjX5]

ok understood. But does this help regarding the wildcard in the src of the route?

[aaronhurt]

I'll have to check the code to be sure. I think it uses the same matcher but I'll have to verify.

[calvix]

Hello,

the TCP SNI wildcard routing indeed doesn't work in a current state.

I have PR that allows the wildcard routing here calvix#1
Question is if this fits the general fabio code and doesn't bring any issues.

[aaronhurt]

Ahh yes, the table lookup function. That's a host key based map lookup. I'll take a look at the PR ... I merged a small change to the lookup function yesterday to force the host portion of all route additions and lookups to be lowercase.