https
73 TopicsHigh CPU utilization (100%).
I observed high CPU utilization (100%) on F5 device, resource provision ASM nominal. I checked the client-side throughput and server-side throughput both are normal but found management interface throughput is very high and what i noticed this is happening in same time period for last 30 days. What could be the reason for this spike. Many thanks in advanced for your time and consideration.146Views0likes14CommentsHSTS is not working.
Hi there, We have one irule is configured on VIP which is redirecting to maintenance page if user access the wrong url on that page HSTS is not working but if we access the right url then HSTS is working. We have enabled HSTS in http profile and that is attached to the same VIP with irule. Is there any way to enable HSTS on maintenance page or any remediation to fix that issue. if { $DEBUG } { log local0. "TEST - Source IP address: [IP::client_addr]" } switch -glob $uri_ext { "/httpfoo*" {set uri_int [string map {"/httpfoo" "/adapter_plain"} $uri_ext]} "/httptest*" {set uri_int [string map {"/httptest" "/adapter_plain"} $uri_ext]} default { HTTP::respond 200 content [ifile get ifile_service_unavailable_html] set OK 0 } } Many thanks in advance.Solved106Views0likes1CommentIncosistent forwarding of HTTP/2 connections with layered virtual
Hi, I'm using a layered virtual configuration: Tier1: Virtual applying SNI-Routing (only SSL persistence profile and LTM policy as described in https://www.devcentral.f5.com/kb/technicalarticles/sni-routing-with-big-ip/282018) Tier2: Virtual applies SSL termination and delivering the actual application, with the required profiles, iRules, .... If the required, an additional LTM policy is applied for URI-based routing and forwards to Tier3 VS. Tier3 (optional, if required): Virtual delivers specific applications, like microservices, usually no monolithical apps. This configuration is very robust and I'm working with it successfully since years. Important: The tier1 uses one single IP address and a single port. So all tier2 and tier3 virtuals MUST be externally available through the same IP address and port. Now I have to publish the first HTTP/2 applications over this concept and see strange behavior of the BIG-IP. User requests www.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests, based on the SNI, to tier2 virtuals "vs-int_www.example.com". Within www.example.com there are references to piwik.example.com, which is another tier2 virtual, behind my tier1 virtual. User requests piwik.example.com. IP and port point to tier1 virtual. Tier1 LTM policy forwards the requests to "vs-int_www.example.com" instead of "vs-int_piwik.example.com". Probably not based on SNI, but on the existing TCP connection. I'm afraid, that this bahvior is a result of HTTP/2, especially because of the persistent TCP connection. I assume that, because the connection ID (gathered from browser devtools) for requests to www.example.com and piwik.example.com is identical. From the perspective of the browser I wouldn't expect such a behavior, because the target hostname differs. I didn't configure HTTP/2 in full-proxy mode, as described in several articles. I've just enabled it on the client-side. I would be very happy for any input on that. Thanks in advance!199Views0likes11CommentsPort Translation & HTTPS -> HTTP
Systeminformation: F5 BIG-IP r2600 Version 17.1.1.1 Build 0.0.2 Hello everyone, We would like to map the following scenario with the f5 BIG-IP I call https://server.domain.com port 443. The BIG-IP should then forward to http://server.domain.com port 55000. Is this even possible? How did you solve it? Configuration: For port translation, we entered port 443 in the virtual server and gave the pool member port 55000. For HTTPS to HTTP we used the following iRule: when HTTP_REQUEST { # Extrahiere den Host und den URI aus der HTTPS-Anfrage set host [HTTP::host] set uri [HTTP::uri] # Leite die Anfrage an die HTTP-Version der gleichen URL weiter HTTP::respond 301 Location "http://$host$uri" log "iRule_HTTP, HTTPS-Anfrage wurde auf HTTP umgeleitet: $host$uri, ClientIP: [IP::client_addr], ClientPort: [TCP::client_port]" } Is the iRule log entry generated before the port translation? The wrong port is in the logs. Best regardsSolved69Views0likes2CommentsRewrite http:// to https:// in response content
Problem this snippet solves: (Maybe I missed it, but) I didn't see a code share for using a STREAM profile to rewrite content from http to https. This share is just to make it easier to find a simple iRule to replace http:// links in page content to https://. It's taken directly from the STREAM::expression Wiki page. How to use this snippet: You'll need to assign a STREAM profile to you virtual server in order for this to work (just create an empty stream profile and assign it). Code : # Example which replaces http:// with https:// in response content # Prevents server compression in responses when HTTP_REQUEST { # Disable the stream filter for all requests STREAM::disable # LTM does not uncompress response content, so if the server has compression enabled # and it cannot be disabled on the server, we can prevent the server from # sending a compressed response by removing the compression offerings from the client HTTP::header remove "Accept-Encoding" } when HTTP_RESPONSE { # Check if response type is text if {[HTTP::header value Content-Type] contains "text"}{ # Replace http:// with https:// STREAM::expression {@http://@https://@} # Enable the stream filter for this response only STREAM::enable } } Tested this on version: 11.53.2KViews0likes5CommentsLineRate HTTP to HTTPS redirect
Here's a quick LineRate proxy code snippet to convert an HTTP request to a HTTPS request using the embedded Node.js engine. The relevant parts of the LineRate proxy config are below, as well. By modifying the redirect_domain variable, you can redirect HTTP to HTTPS as well as doing a non-www to a www redirect. For example, you can redirect a request for http://example.com to https://www.example.com . The original URI is simply appended to the redirected request, so a request for http://example.com/page1.html will be redirected to https://www.example.com/page1.html . This example uses the self-signed SSL certificate that is included in the LineRate distribution. This is fine for testing, but make sure to create a new SSL profile with your site certificate and key when going to production. As always, the scripting docs can be found here. redirect.js: Put this script in the default scripts directory - /home/linerate/data/scripting/proxy/ and update the redirect_domain and redirect_type variables for your environment. "use strict"; var vsm = require('lrs/virtualServerModule'); // domain name to which to redirect var redirect_domain = 'www.example.com'; // type of redirect. 301 = temporary, 302 = permanent var redirect_type = 302; vsm.on('exist', 'vs_example.com', function(vs) { console.log('Redirect script installed on Virtual Server: ' + vs.id); vs.on('request', function(servReq, servResp, cliReq) { servResp.writeHead(redirect_type, { 'Location': 'https://' + redirect_domain + servReq.url }); servResp.end(); }); }); LineRate config: real-server rs1 ip address 10.1.2.100 80 admin-status online ! virtual-ip vip_example.com ip address 192.0.2.1 80 admin-status online ! virtual-ip vip_example.com_https ip address 192.0.2.1 443 attach ssl profile self-signed admin-status online ! virtual-server vs_example.com attach virtual-ip vip_example.com default attach real-server rs1 ! virtual-server vs_example.com_https attach virtual-ip vip_example.com_https default attach real-server rs1 ! script redirect source file "proxy/redirect.js" admin-status online Example: user@m1:~/ > curl -L -k -D - http://example.com/test HTTP/1.1 302 Found Location: https://www.example.com/test Date: Wed, 03-Sep-2014 16:39:53 GMT Transfer-Encoding: chunked HTTP/1.1 200 OK Content-Type: text/plain Date: Wed, 03-Sep-2014 16:39:53 GMT Transfer-Encoding: chunked hello world222Views0likes0CommentsHTTP is fast, HTTPS really slow and causes massive FCS failure
I have two BIGIP VE's on my laptop I use for lab and education. On both of them (not HA) HTTPS to a VS works, but is painfully slow. A simple web page with a few pictures in it takes 20-30 seconds to load. Unencrypted HTTP is lightning fast. Here is the VS config: ltm virtual /Common/f5trn.cmos.lab-p443-vs { destination /Common/10.1.10.20:443 ip-protocol tcp mask 255.255.255.255 pool /Common/f5trn.cmos.lab-pool profiles { /Common/f5trn.cmos.lab { context clientside } /Common/http { } /Common/http2 { } /Common/tcp { } } source 0.0.0.0/0 translate-address enabled translate-port enabled } ltm pool /Common/f5trn.cmos.lab-pool { members { /Common/10.1.20.11:80 { address 10.1.20.11 } /Common/10.1.20.12:80 { address 10.1.20.12 } /Common/10.1.20.13:80 { address 10.1.20.13 } } monitor /Common/http } A packet capture shows a MASSIVE FCS failure. Every single frame. Same on both sides of the BIGIP. Troubleshooting includes: Disabling SSL (removing clientSSL profile). Not slow. Disabling HTTP/2 profile, using HTTP/1.1 (with SSL) instead. Still slow. Using normal clientssl profile. Still slow. Trying another BIGIP VE on the same laptop (standalone). Still slow. Upgrading virtual hardware from v7 to v12. Still slow. Upgrading memory on BIGIP VE 6 > 8 GB RAM. Still slow. CPU load is around 9% Memory usage is >80% high according to the flash-based dashboard. 6 or 8 GB RAM makes no difference. However TMM uses 5.5% of 3.9 GB. The Configuration Utility uses HTTPS and is very responsive. Other info: LTM, APM and AVR are provisioned The FQDN is resolved via /etc/hosts file BIGIP version is 13.1 My laptop is a MacBook Pro with core i7 with 16GB RAM and not slow or heavily loaded with anything else. Any ideas to why SSL seems to cause this behaviour?521Views0likes2CommentsHTTPS Monitor fails after changing TLS Version
Hello, following problem: we've some pools with https monitors like this: send string:GET /some/pingservlet HTTP/1.0\r\n\r\n receive string: 200 OK no alias service port, no server ssl-profile now the server admin changed on the server from apache with tls 1.0 to tomcat with tls 1.2 after that the monitor fails, but when I change on the pool the monitor to tcp or something like this, the server is up and now I change the monitor back to the original https monitor, the server is still up when I check with curl -vk when the Server marks down i could still see "HTTP/1.1 200 OK" Any idea, why the the monitor fails and after change and change back the monitor shows up? Thank YouSolved1.3KViews0likes4Comments"Could not uncompress compressed request content" error
Hi, I have a LTM (v10.2.4) setup to handle the following: Client ---- (HTTPS POST with compressed payload) ---> F5 ------- (HTTP decompressed payload) -----> Pool member When client sends compressed payload, there are no issues. When client sends un-compressed payload (json), the f5 returns the below error: "uncompressRequest caught exception: \"message\" = \"Could not uncompress compressed request content" Is there a way to configure F5 to handle both compressed and uncompressed payload at the same time. I believe the 'Profile' for 'HTTP' is handling this and this is the custom http profile that I have: profile http http_custom1 { defaults from http insert xforwarded for enable } Here are the headers in https POST: x-generic-protocol-version: 1.0 Accept: application/json Accept: application/json content-encoding: gzip content-type: application/json Accept-Encoding: gzip Thank you for your time.Solved419Views0likes1CommentMobile browsers broken - https redirect
BigIP 1600's - v11.6 HF 4 I have a simple iRule that forces https and strips the www. We have a CMS running that automatically detects the user agent, and redirects the mobile browser to the mobile version of the website. As soon as I applied the following iRule, mobile browsers appeared to be broken upon the first initial page load request. With mobile Safari on iOS, (as well as Android) I get the following message when I browse the site: "Safari cannot open the page because it could not load any data" If I refresh the page a 2nd time, the mobile version of the website loads. What would be the best way to troubleshoot this? Would I need to implement logging to capture the user agent, and where the client is trying to go? Why would a refresh cause the page to load on the 2nd attempt? Here's the iRule: when HTTP_REQUEST { if {([string tolower [HTTP::host]] starts_with "www.")} { HTTP::redirect "https://[string range [HTTP::host] 4 end][HTTP::uri]" return } elseif { [TCP::local_port] == 80 } { HTTP::redirect https://[HTTP::host][HTTP::uri] return } }426Views0likes3Comments