Blazor WebSocket WebApp behind APM not working...
Dear community, we a trying to host a new web-application using Websockets. I created a websocket profile - but we always get the following errors: [2024-12-13T18:28:56.102Z] Information: Normalizing '_blazor' to 'https://remote-t.dfg.de/f5-w-687474703a2f2f73727767743238312e696e742e742e6466672e6465$$/f5-h-$$/_blazor'. blazor.server.js?F5CH=J:1 [2024-12-13T18:28:56.219Z] Warning: Failed to connect via WebSockets, using the Long Polling fallback transport. This may be due to a VPN or proxy blocking the connection. To troubleshoot this, visit https://aka.ms/blazor-server-using-fallback-long-polling. log @ blazor.server.js?F5CH=J:1 blazor.server.js?F5CH=J:1 [2024-12-13T18:28:56.267Z] Error: The circuit failed to initialize. log @ blazor.server.js?F5CH=J:1 blazor.server.js?F5CH=J:1 [2024-12-13T18:28:56.375Z] Information: Connection disconnected. blazor.server.js?F5CH=J:1 Uncaught (in promise) Error: Invocation canceled due to the underlying connection being closed. at Xt._connectionClosed (blazor.server.js?F5CH=J:1:62068) at Xt.connection.onclose (blazor.server.js?F5CH=J:1:51976) at pn._stopConnection (blazor.server.js?F5CH=J:1:91786) at features.reconnect.transport.onclose (blazor.server.js?F5CH=J:1:89471) at hn._raiseOnClose (blazor.server.js?F5CH=J:1:76756) at hn.stop (blazor.server.js?F5CH=J:1:76567) at async pn._stopInternal (blazor.server.js?F5CH=J:1:84144) at async pn.stop (blazor.server.js?F5CH=J:1:83975) at async Xt.stop (blazor.server.js?F5CH=J:1:55012) at async Ir.disconnect (blazor.server.js?F5CH=J:1:137836) Without APM, the Website ist working fine. What am I doing wrong? I value and appreciate your time and energy and look forward to hearing from you. Thank you.F5 AWAF with HTTP/2, MRF and Websocket profiles
Good day all, I have F5 Big-IP AWAF's (version 16.1.4.3) and I am trying to configure HTTP/2 with MRF. My colleague and I discovered that Websocket profiles on the Virtual Server don't play well when enabling MRF. Is there a way to enable a "hybrid" configuration using websocket and HTTP/2 with MRF? I value and appreciate your time and energy and look forward to hearing from you. Thank you.
iRule to decode WebSocket negotiation and frames
Problem this snippet solves: WebSocket establishes a socket via HTTP upgrade and once socket is established subsequent messages are non-HTTP, but WebSocket frame. There might be a situation where you want to dump WebSocket negotiation and frame into log for troubleshooting purpose. This iRule dumps negotiation and WebSocket frame header fields, and payload (only text data). WebSocket frame format looks as below. RFC 6455 - 5.2. Base Framing Protocol 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ WebSocket frame is quite simple. The first 2 bytes are necessary and always present. Extended payload length exists only when Payload length is set to 126 (in this case Ext len is 16 bits) or 127 (in this case Ext len is 64 bits). Masking-key exists only if MASK bit is set to 1. FIN : If the frame is the last frame, set to 1. If payload is fragmented, the last frame should have FIN = 1. Other fragmented ones should have FIN = 0. RSV : If extension is not used, it is set to 0 opcode : This tells you if it is data frame (can be text or binary) or control frame. %x0:continuation frame %x1:text frame %x2:binary frame %x3-7:reserved for further %x8:connection close %x9:ping %xA:pong %xB-F:reserved for further MASK : When browser sends a data, this bit MUST be set to 1, which means data is masked using the Masking-key. When server sends a data, this bit MUST NOT set to 1 Payload len : If 0 - 125, this field represents the payload length If it is 126, then the Extended payload length (16bit) are used to tell the actual payload length (maximum data size is 65535 bytes) If it is 127, then the Extended payload length (64bit : MSB must be 0) are used to tell the actual payload length (maximum data size is 9223372036854775807 bytes) Extended payload length Only when Payload len is set to 126 Extended payload length_continued Only when Payload len is set to 127 Masking-key Used to mask data. Masking is to avoid proxy poisoning. Non-compliant HTTP proxy caches WebSocket data. If MASK bit is 1, this field is present. If MASK bit is 0, this field is not present. Client sets this key and it must be unpredictable. Payload Payload from client to server is masked using Masking-key. How to use this snippet: Here I am sending text data "DEAD BEEF" in WebSocket frame via WebSocket_cURL.py (https://github.com/jussmen/WebSocket_cURL). HTTP request and response (negotiation) look like below. $ python WebSocket_cURL.py 10.10.148.101 80 -s "DEAD BEEF" GET /ws HTTP/1.1 Host: 10.10.148.101 Connection: Upgrade Upgrade: websocket Sec-WebSocket-Version: 13 Sec-WebSocket-Key: n5twxG/tNPf8h3po+pNrPA== User-Agent: IE HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: y9WDs+d4zDl+qvQ7H17KpnP0EhI= This is how iRule dumps the negotiation and subsequent WebSocket frames in /var/log/ltm <ws_request>: ============================================= <ws_request>: Client 10.10.1.2:47427 -> 10.10.148.101/ws (request) <ws_request>: Host: 10.10.148.101 <ws_request>: Connection: Upgrade <ws_request>: Upgrade: websocket <ws_request>: Sec-WebSocket-Version: 13 <ws_request>: Sec-WebSocket-Key: n5twxG/tNPf8h3po+pNrPA== <ws_request>: User-Agent: IE <ws_request>: ============================================= <ws_response>: ============================================= <ws_response>: Client 10.10.1.2:47427 -> 10.10.148.101/ws (response) <ws_response>: Upgrade: websocket <ws_response>: Connection: Upgrade <ws_response>: Sec-WebSocket-Accept: y9WDs+d4zDl+qvQ7H17KpnP0EhI= <ws_response>: ============================================= <ws_server_frame>: ============================================= <ws_server_frame>: FIN bit : 1 <ws_server_frame>: MASK bit : 1 <ws_server_frame>: MASK : 0 <ws_server_frame>: Type : Text - 1 <ws_server_frame>: ============================================= <ws_server_data>: ============================================= <ws_server_data>: The server says: 'Hello'. Connection was accepted. <ws_server_data>: ============================================= <ws_client_frame>: ============================================= <ws_client_frame>: FIN bit : 1 <ws_client_frame>: MASK bit : 1 <ws_client_frame>: MASK : 1178944834 <ws_client_frame>: Type : Text - 1 <ws_client_frame>: ============================================= <ws_client_data>: ============================================= <ws_client_data>: DEAD BEEF <ws_client_data>: ============================================= <ws_server_frame>: ============================================= <ws_server_frame>: FIN bit : 1 <ws_server_frame>: MASK bit : 1 <ws_server_frame>: MASK : 0 <ws_server_frame>: Type : Text - 1 <ws_server_frame>: ============================================= <ws_server_data>: ============================================= <ws_server_data>: The server says: DEAD BEEF back at you <ws_server_data>: ============================================= <ws_client_frame>: ============================================= <ws_client_frame>: FIN bit : 1 <ws_client_frame>: MASK bit : 1 <ws_client_frame>: MASK : 1178944834 <ws_client_frame>: Type : Connection close - 8 <ws_client_frame>: ============================================= <ws_server_frame>: ============================================= <ws_server_frame>: FIN bit : 1 <ws_server_frame>: MASK bit : 1 <ws_server_frame>: MASK : 0 <ws_server_frame>: Type : Connection close - 8 <ws_server_frame>: ============================================= Code : when WS_REQUEST { # Copied from : https://devcentral.f5.com/s/articles/log-http-headers set LogString "Client [IP::client_addr]:[TCP::client_port] -> [HTTP::host][HTTP::uri]" log local0. "=============================================" log local0. "$LogString (request)" foreach aHeader [HTTP::header names] { log local0. "$aHeader: [HTTP::header value $aHeader]" } log local0. "=============================================" } when WS_RESPONSE { # Copied from : https://devcentral.f5.com/s/articles/log-http-headers log local0. "=============================================" log local0. "$LogString (response)" foreach aHeader [HTTP::header names] { log local0. "$aHeader: [HTTP::header value $aHeader]" } log local0. "=============================================" } when WS_CLIENT_FRAME { log local0. "=============================================" log local0. "FIN bit : [WS::frame eom]" log local0. "MASK bit : [WS::frame orig_masked]" if { [WS::frame orig_masked] eq 0 } { log local0. "Not masked. Client frame MUST be masked." } if { [WS::frame orig_masked] eq 1 } { log local0. "MASK : [WS::frame mask]" } switch -glob [WS::frame type] { "0" { log local0. "Type : Continuatoin frame - 0" } "1" { log local0. "Type : Text - 1" WS::collect frame } "2" { log local0. "Type : Binary - 2" } "3" - "4" - "5" - "6" - "7" { log local0. "Type : Reserved type (3-7) - [WS::frame type]" } "8" { log local0. "Type : Connection close - 8" } "9" { log local0. "Type : ping - 9" } "10" { log local0. "Type : pong - 10" } "11" - "12" - "13" - "14" - "15" { log local0. "Type : Reserved type (11-15) - [WS::frame type]" } } log local0. "=============================================" } when WS_SERVER_FRAME { log local0. "=============================================" log local0. "FIN bit : [WS::frame eom]" log local0. "MASK bit : [WS::frame orig_masked]" if { [WS::frame orig_masked] eq 1 } { log local0. "MASK : [WS::frame mask]" } switch -glob [WS::frame type] { "0" { log local0. "Type : Continuatoin frame - 0" } "1" { log local0. "Type : Text - 1" WS::collect frame } "2" { log local0. "Type : Binary - 2" } "3" - "4" - "5" - "6" - "7" { log local0. "Type : Reserved type (3-7) - [WS::frame type]" } "8" { log local0. "Type : Connection close - 8" } "9" { log local0. "Type : ping - 9" } "10" { log local0. "Type : pong - 10" } "11" - "12" - "13" - "14" - "15" { log local0. "Type : Reserved type (11-15) - [WS::frame type]" } } log local0. "=============================================" } #when WS_CLIENT_FRAME_DONE { #log local0. "WS_CLIENT_FRAME_DONE" #} #when WS_SERVER_FRAME_DONE { #log local0. "WS_SERVER_FRAME_DONE" #} when WS_CLIENT_DATA { log local0. "=============================================" log local0. "[WS::payload]" log local0. "=============================================" WS::release } when WS_SERVER_DATA { log local0. "=============================================" log local0. "[WS::payload]" log local0. "=============================================" WS::release } Tested this on version: 12.0
Issues with reverse proxying the application using socket.io and Secure Websockets
Hello, I am trying to setup a reverse proxy for the application written with socket.io which tries to upgrade the connection to Secure Websockets. Looking at the docs WSS should be supported in BIG-IP 11.5.4, however I am getting some connection errors as per below (trace from the Firebug): The connection to wss://host.example.com/launchpad/socket.io/?EIO=3&transport=websocket&sid=GTQLD62vWeuwQwIzAAIp was interrupted while the page was loading. socket.io.js (line 3, col 1049) Are there any limitations known when using LTM and WSS ? In my existing lab configuration I am using both rewrite rules and stream profiles to rewrite URLs. Thanks a lot for any comments Regards
using websocket via ASM
Hi all. I'm testing about ASM v11.4.1 and a website using websocket. I wonder ASM can support websocket. In my test, LTM can support websocket but ASM can't support it. When apply ASM policy to VirtualServer, I can't show websocket part. So I made a iRule, that is below: when CLIENT_ACCEPTED { HTTP::enable } when HTTP_REQUEST { if { ([string tolower [HTTP::header value Upgrade]] equals "websocket" ) && ([string tolower [HTTP::header value Connection]] equals "upgrade" ) } { log local0. "HTTP Disable" ASM::disable } } In this iRule, when websocket traffic is come, it disable ASM and pass to LTM. But it means, if some web attacks are come through websocket, ASM can't block attacks. In addition, if i change iRule from ASM::disable to HTTP::disable, page loading is slowed. Does any solution using with ASM and websocket?
Websocket iRule
Hello everybody, hope you could help me with this , my thinking is this needs custom iRule . We are using Mango Automation system , and when we put it behind F5 LTM some parts (like gauges etc.) stop to function. I see these are websocket connections? Does anybody have experience with this ? They even have some documentation for Apache rev. proxy here in the link: https://docs-v4.mango-os.com/proxy thanks Damir
