Mattermost, F5 LTM, and Websockets
I recently worked with a team that wanted to use the F5 Local Traffic Manager (LTM) feature to load balance connections to their new deployment of the Mattermost open source messaging platform within their on-premises datacenter. This application uses both HTTPS and Websockets connections for real-time chat. We ran into a few configuration issues but eventually found the right combination of “nerd knobs” to allow successful ingress traffic. This post is to consolidate these details and hopefully save time to other F5 engineers attempting to do the same. Business Requirements Ingress (client-side) connections TLS 1.1 or higher Support Websockets Only allow customized Mattermost mobile (iOS and Android) applications, provisioned from within the organization and using a custom header, to connect from the public Internet. The same VIP for the mobile traffic should be used by internal desktop or web browsers, which will not include this custom header Virtual Server Configuration The virtual server configuration was fairly straight forward: Protocol Profile (Client) = a mobile optimized TCP profile Protocol Profile (Server) = a LAN optimized TCP profile SSL Profile (Client) = profile with the Option No TLSv1 enabled SSL Profile (Server) = standard serverssl profile or custom one WebSocket Profile = WebSocket (or a custom one with this as the parent) SNAT = custom pool, but AutoMap would work OneConnect = standard oneconnect profile (or a custom one with this as the parent) Default Persistence = cookie Fallback Persistence = source address Pool = Mattermost server pool iRule = custom Mattermost iRule Mattermost iRule To meet some of the business requirements a custom iRule was created to handle some of the conditions outlined. Comments in-line, but this checks to see if the connection was outside of the organization and if so verifies the presence of the custom HTTP header and value. This also checks to see if the connection was requested to upgrade to Websockets, and if it is, change the HTTP filter from full parsing to passthrough mode. when HTTP_REQUEST { if { !(IP:addr [IP::client_addr] equals 192.168.0.0/255.255.255.0]) } { Request from IP outside of organization, check for customer HTTP header if { [HTTP::header x-the-custom-http-header-name] contains "customvalue" } { Custom HTTP header and matching value found if { [string tolower [HTTP::header Upgrade]] contains "websocket" }{ Connection is requesting WebSockets, stop HTTP parsing HTTP::disable } } elseif { [HTTP::cookie exists MMAUTHENTOKEN] && [HTTP::cookie exists MMUSERID] } { Since WebSocket connections do not have HTTP Header, check to see if connection has already authenticated and allow the connection return } else { Connection fails conditions, reject it reject } } else { if { [string tolower [HTTP::header Upgrade]] contains "websocket" }{ Connection is requesting WebSockets, stop HTTP parsing HTTP::disable } } }