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 } } }
Linerate 2.6.1 / Socket.IO - Express
Suppose a farm of Nodejs servers, running Express and Socket.IO, without any reverse proxy such as apache or nginx. Express and Socket.IO are running in HTTPS Is Linerate support Express and Websocket ( socket.io ). I tried to several setup such as VIP ( HTTP:443 ) ---> VS ( HTTP ) ---> RS ( HTTP ) with the right SSL Profile and Hostname or VIP ( TCP:443 ) ----> VS ( TCP ) ----> RS ( TCP ) with the right SSL profile and Hostname Nothing to do, this does not work and claiming for 404 not found. However, with the same setup for regular PHP Backends it was working. Any advices ? Is there any online ressources on how accomplish this setup on linerate ?
iRule for supporting WebSocket in LTM v10.2.4
Hi, We had developed an iRule for support WebSocket in LTM v10.2.4 HF7 (Although 11.4 had native support, but we had no plan to upgrade currently) Sample handshake (http://en.wikipedia.org/wiki/WebSocketWebSocket_protocol_handshake) when HTTP_RESPONSE { if status code is 101 (Switching Protocols) and there exists HTTP header "Upgrade: WebSocket", that means we are switching to WebSocket and thus HTTP filter shall be disabled use case insensitive matching if { [HTTP::status] == 101 && "websocket" eq [string tolower [HTTP::header value "Upgrade"]] } { HTTP::disable } } But it does not work. Adding debug message found that I never saw HTTP::status returns 101 (I had confirmed with tcpdump that the server did reply with status code 101). So I doubt that there are something wrong for handling this status code in LTM v10.2.4 HF7. Currently I had used the following iRule which is less secure as it will disable HTTP filter once client request to switch to WebSocket without confirmation from server. when HTTP_REQUEST { if client request contains a HTTP header "Upgrade: WebSocket", it indicate the client intended to switch to WebSocket, we shall disable HTTP filter here it is not very secure as we shall wait for response from server to confirm with status code 101 (Switching Protocols) with HTTP header "Upgrade: WebSocket" but it seems that LTM 10.2.4 HF7 have problem on that status code, so we have to workaround it. use case insensitive matching if { "websocket" eq [string tolower [HTTP::header value "Upgrade"]] } { HTTP::disable } } 2 questions 1. Is there any problem in the support of status code 101 in LTM v10.2.4 HF7? 2. Any existing iRule for supporting WebSocket?
SSL off-loading and secure WebSocket
Hi, We have a Big-IP load balancer, and we are planning to publish a web application that uses secure WebSockets (WSS). We are a little bit concerned about how the load balancer is going to handle this situation, because the SSL offloading. Is there anything special we have to configure or taken care off? Clients will send an HTTPS request with a WebSocket handshake, that includes the HTTP headers "Upgrade:websocket" and "Connection:Upgrade". Will the load balancer populate those headers to the web server? Will the load balancer understand that those connections are persistent and non-HTTP? Thanks.