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!
HTTP 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?
Mobile 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 } }
Redirect 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.... Cheershttps 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 .
