Incosistent 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!196Views0likes11CommentsPort 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 regardsSolved59Views0likes2CommentsHTTP 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?516Views0likes2CommentsHTTPS 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 } }420Views0likes3CommentsSSLO HTTPS conversion to HTTP for NGFW inspection
Hi all, I am new to the bigip SSLO and I was playing around it in order to see if I can enhance my NGFW visibility instead of moving to a bigger box. The BIGIP has been moved as the default gateway for all users and acts as a transparent proxy. All users have been provisioned the CA certificate and exceptions for pinned and sensitive sites have been provisioned and working as intended. The main idea is that I want to decrypt HTTPS traffic and send it over a Layer2/3 path via the NGFW in order to examine traffic and then re-encrypt it before been sent over to the internet. I have everything working as intended except the HTTPS-to-HTTP-to-HTTPS. Is this something which can be done by the SSLO? Thank you KonstantinosSolved1.7KViews0likes10CommentsF5 Telmeter to Node Exporter
Hello, I want to stream F5 Telemetry to Node_exporter because node exporter is integrated with Oracle cloud. how ever the node_exporter config accepts only HTTP URLs as we know the F5 endpoint is HTTPS and also uses a user/password. the endpoint I have tested working on POSTMAN. any workaround for that?Solved1.5KViews0likes5CommentsRedirect TCP connections from port 443 to 80
Hi All We have a port 80 and 443 VIP configured for 301 redirections to send sites to specific pages on a target branding site. We use 301 redirects and it works just fine via irule. However, for this to work for HTTPS requests, we need a cert and SSL profile to decrypt the request and then redirect it. The same irule is in use for both the 80 and 443 VIPs I'm wondering whether it's possible to do a basic 'when client_accept/connect' irule to force ALL connections to the VIP to go to the port 80 version so that we don't need to keep purchasing certs for 'old' websites. Perhaps another option would be to set a single client_ssl profile on the 443 VIP, use a 'when clientssl_handshake' iRule and try redirect to 80 that way, but I have my doubts. This is a bit beyond my current iRule skills.... Cheers1.9KViews0likes1Commenthttps connection with URI shows as not secured ?
Hi Team , We have a new VIP with url https://example.test.com , but when we try to access the url with uri it says "The information you're bout to submit is not secure " https://example.test.com >> WORKS https://example.test.com/sap/saml2/sp/acs/100 >> error : "The information you're bout to submit is not secure " Please advice .1.3KViews1like6Comments