SNI Routing with BIG-IP

Thanks!

Your iRule is very nice and useful if you want to combine with tactics like TLS Fingerprinting.

AFAIK, the requirement for SSL persistence profile enables inspection of the connection without requiring a clientssl profile. Normally it is used to extract the SSL session ID, but the TLS extensions is also available.

To prove that no clientssl profile is required, here's an example from my lab setup (using tmsh output).

ltm virtual test_vs {
    destination 192.0.2.10:443
    ip-protocol tcp
    mask 255.255.255.255
    persist {
        ssl {
            default yes
        }
    }
    policies {
        sni_routing { }
    }
    profiles {
        tcp { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vs-index 5
}

and here's the matching policy (the screenshots in the article are inverted from my diagram, I updated the following to match the diagram).

ltm policy sni_routing {
    controls { forwarding }
    last-modified 2018-05-23:00:37:54
    requires { client-ssl }
    rules {
        rule_001 {
            actions {
                0 {
                    forward
                    ssl-client-hello
                    select
                    virtual /Common/test_ssl_vs
                }
            }
            conditions {
                0 {
                    ssl-extension
                    ssl-client-hello
                    server-name
                    values { app1.example.com }
                }
            }
            description sni:app1.example.com,virtual:test_ssl_vs
            ordinal 2
        }
        rule_002 {
            actions {
                0 {
                    forward
                    ssl-client-hello
                    select
                    pool test_ssl
                }
            }
            conditions {
                0 {
                    ssl-extension
                    ssl-client-hello
                    server-name
                    values { app2.example.com }
                }
            }
            description sni:app2.example.com,pool:test_ssl
            ordinal 3
        }
    }
    status published
    strategy first-match
}

On version 13.1 (used above) it will show in the policy requires "client-ssl", prior to that you will see "ssl-persistence". In either version you can use the policy w/out a clientssl profile as you can see in the earlier output.

You can verify all is well by using openssl

[demo]$ echo | openssl s_client -showcerts -servername app1.example.com -connect 192.0.2.10:443 2>/dev/null |grep "subject="
subject=/CN=app1.example.com
[demo]$ echo | openssl s_client -showcerts -servername app2.example.com -connect 192.0.2.10:443 2>/dev/null |grep "subject="
subject=/CN=app2.example.com

Checking out the stats via the GUI or TMSH is helpful too.

(tmos) show /ltm policy sni_routing

---------------------------
Ltm::Policy: sni_routing
---------------------------
Virtual Server Name     N/A

Status
  Actions invoked   :     7
  Actions succeeded :     7

  --------------------------------------------------
  | Rule                  Action  Invoked  Succeeded
  --------------------------------------------------
  | rule_001  0 [forward select]        4          4
  | rule_002  0 [forward select]        3          3

adding the second virtual for completeness. In this case the SSL certificate is known by the BIG-IP (app1.example.com). The second pool "test_ssl" points directly to the backend web server and the BIG-IP does not have the certificate (app2.example.com).

The virtual listens on port 9443, but you could also use a different private address and/or restrict connections (i.e. set the source to be 192.0.2.10/32).

ltm virtual test_ssl_vs {
    destination 192.0.2.10:9443
    ip-protocol tcp
    mask 255.255.255.255
    pool test_pool
    profiles {
        app1.example.com_clientssl {
            context clientside
        }
        http { }
        tcp { }
    }
    source 0.0.0.0/0
    source-address-translation {
        type automap
    }
    translate-address enabled
    translate-port enabled
    vs-index 10
}

Re: performance

I have not done any performance comparison.

Re: iRule for enable client/server ssl profile

You can only select a server ssl profile from a Local Traffic Policy. IMHO it makes sense to use a Local Traffic Policy as "tier 1" that uses VIP targeting (via the policy) to multiple different virtual servers that have different clientssl profile attached.

Alternately, you could set a variable in the local traffic policy and later use an iRule (attached to the same virtual server as the local traffic policy) to assign the clientssl profile via SSL::profile (I have not tried this, seems plausible).

not sure if that answers your question.

Re: why ssl persistence

My best guess is that it exposes variables that are necessary by Local Traffic Policy. For example if you try to invoke an iRule that acts on the CLIENTSSL_CLIENTHELLO event you will get the following error

01071912:3: CLIENTSSL_CLIENTHELLO event in rule (/Common/test_sni) requires an associated CLIENTSSL or PERSIST profile on the virtual-server (/Common/test_sni).

Re: ssl persistence on pool

If you are sending traffic to a pool you may want to have a combination of ssl persistence and source ip persistence. otherwise you could see an issue where a client will renegotiate the ssl session. this could occur when reconnecting and getting sent to a different backend server.

agree that the behavior could be unwanted depending on the use-case. typically you want to preserve connections to the same backend for SSL connections.

Thanks for your feedback/questions!

Eric