When user goes through LB the server page has stripped information
I have created a pretty simple round robin load balancing for a user with three servers. As a part of this I also have DNS LB in place that sends the traffic to two VIPs that are connected to the three nodes in a pool I have created on my LTM F5. User accesses the LB DNS URL I provide via Https://<>.com > VIP > Pool > Nodes. There is a certificate applied to the clientssl and serverssl profiles attached to the VIPs. The user is able to get to their backend servers/nodes when going through the load balancer, but we are coming across an interesting issue. When the user goes through the F5 the server dashboard page they usually see is stripped of information on that dashboard. Typically, there would be tiles shown on the server dashboard, but it is just the basic UI and none of the tiles. When the user goes directly to their server, all the information/tiles are shown as normal. I have never experienced this problem before and am not sure how to prove out the F5 is causing the issue or how it is happening. Any insight would be greatly appreciated! *Attached file shows what I'm explaining.
Help with iRule Proxy
Hi team, I’m working on an iRule where I need to replace the path /admin with the root / and forward the request to the appropriate pool. However, I’m encountering issues with the rule, and it doesn't seem to work as expected. Here’s the first version I implemented: when HTTP_REQUEST { if {[string tolower [HTTP::host]] equals "test.com" and [HTTP::path] starts_with "/admin"} { HTTP::path [string map -nocase {"/admin" "/"} [HTTP::path]] pool POOL-A #log local0.info "Client Address --> [IP::client_addr] | Path: [HTTP::path] | Pool: POOL-A" } else { pool POOL-B #log local0.info "Client Address --> [IP::client_addr] | Path: [HTTP::path] | Pool: POOL-B" } } After some research, I saw that HTTP::path might need to be changed to HTTP::uri. I tried this version: when HTTP_REQUEST { # Log the original URI for debugging log local0. "Original URI: [HTTP::uri]" # Check if the URI starts with "/admin" if {[HTTP::uri] starts_with "/admin"} { # Modify the URI by replacing "/admin" with "/" set new_uri [string map {"/admin" "/"} [HTTP::uri]] HTTP::uri $new_uri # Log the modified URI for debugging log local0. "Modified URI: [HTTP::uri]" # Forward the request to the appropriate pool pool POOL-A } else { # Log default traffic for debugging log local0. "Default traffic - URI: [HTTP::uri], Pool: POOL-B" # Forward to the default pool pool POOL-B } } Issue: Neither version seems to work. When I test requests to /admin, the path replacement does not happen as expected or The replace of path does not allow me to reach any subfolders after root “/” (ex. help, etc etc) and on these objects we faced 404 not found error.Could someone point out what I might be missing or any best practices for this kind of path manipulation? Thanks!
Unable to login with Certificate Manager local user
I've created a local user account with the Certificate Manager role on All partitions - and have enabled tmsh access. However, when I attempt to login with this account - either GUI or SSH - I am receiving a login failed message. We don't have any password enforcement in place and access restrictions are tied to the RFC1918 address space, so that is not coming into play. We have remote auth (TACACS) enabled with fallback to local and other local accounts are able to login successfully. Thoughts? Version: 17.1.1.2 Username - cert-mgr Role - Certificate Manager Partition: All Terminal Access: tmsh Wed Sep 11 10:51:20 CDT 2024 cert-mgr 0-0 httpd(pam_audit): User=cert-mgr tty=(unknown) host=x.x.x.x failed to login after 1 attempts (start="Wed Sep 11 10:51:18 2024" end="Wed Sep 11 10:51:20 2024").: Wed Sep 11 11:00:20 CDT 2024 cert-mgr 0-0 httpd(pam_audit): User=cert-mgr tty=(unknown) host=x.x.x.x failed to login after 1 attempts (start="Wed Sep 11 11:00:18 2024" end="Wed Sep 11 11:00:20 2024").:APM subsession variables disappear before session is terminated
Hi We are currently trying to access APM subsession variables in a Per-Request policy. The subsession variables contains user information gathered when validating users with a OAuth client "branch". We would like to keep the username eg. subsession.oauth.client.last.id_token.preferred_username throughout the entire session. However, after around 15 minutes it disappears but the session remains (this matches the Max subsession life timeout value of 900 seconds). When the subsession expires users are not validated once more as their session is still valid and the subsession variable is now "blank". This makes the session logs "anonymous" after 900 seconds and requires extended log searching to find the user of the session (searching for the session ID and finding the originating username from when the session was established). It seems that it is not possible to persist subsession variables to the main session variables. If I add the OAuth branch in the Per Session policy the variables persists, which I would assume is expected behavior. However, this is not a feasible solution, as we branch HTTP HOST's and validate users with different OAuth Servers (Azure App reg). This is only possible in the Per-Request policy. Any advise would be greatly appreciated :-)
Creating iRule for Persistence Profile
Dear Community, Could you assist me in creating an iRule for a Persistence Profile requirement related to an SSO application? When users access our application via desktop, they are presented with a QR code for scanning through a mobile app to authenticate and gain access. The issue arises when, after browsing the website from the desktop (with the session routed to one node via F5 LTM), another request from the mobile app after scanning the QR code is routed to a different node. Ideally, both requests should be directed to the same node. To resolve this, the iRule needs to compare the var topic parameter with the QR_AUTHENTICATION_CHANNEL_ID from the mobile request and ensure both are directed to the same node attached is the screenshot of the code and HTML code of the website /*<![CDATA[*/ var endpoint = "\/qr-websocket"; var topic = "80f95f6f-cecf-4ab6-a70b-1196194e4baa"; var prefix = "\/qrtopic"; var stompClient = null; $(function () { var socket = new SockJS(endpoint); stompClient = Stomp.over(socket); stompClient.connect({}, function (frame) { stompClient.subscribe(prefix + '/' + topic + '/verify', function (result) { console.log(result.body); let body = JSON.parse(result.body); if (body.error) { $("#qrerror").show(); } else if (body.success) { stompClient.disconnect(); $("#qrerror").hide(); $("#qrform #token").val(body.token); $("#qrform #deviceId").val(body.deviceId); $("#qrform").submit(); } }); }); }); /*]]>*/ Regards Omran Mohamed
