Forum Discussion
Zuke
Cirrostratus
CirrostratusBIG-IQ : Error when adding device
I'm standing up a new pair of APM/LTM guests on a BIG-IQ CM. When I add the guests, the standby APM guest fails to import. From the BIG-IQ GUI, I get this message: Trust establishment fail...
curl --verbose -sku "admin:<redacted>" https://bigip2/mgmt/shared/identified-devices/config/device-info | jq -r > GET /mgmt/shared/identified-devices/config/device-info HTTP/1.1 > Authorization: Basic YWRtaW46XmlhTCpSXlBCaC54ajgzOHVLLzhA > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 OpenSSL/1.0.1l zlib/1.2.3 libidn/1.18 > Host: <redacted> > Accept: */* > < HTTP/1.1 400 Bad Request < Date: Wed, 05 May 2021 15:02:27 GMT < Server: Jetty(9.2.22.v20170606) < Set-Cookie: BIGIPAuthCookie=SN8F4Fr0VS8JJ4KZDAobOZ4BkXkfRKADH22x2Hpa; path=/; Secure; HttpOnly < Set-Cookie: BIGIPAuthUsernameCookie=admin; path=/; Secure; HttpOnly < X-Frame-Options: SAMEORIGIN < Strict-Transport-Security: max-age=16070400; includeSubDomains < Content-Type: application/json; charset=UTF-8 < Pragma: no-cache < Cache-Control: no-store < Cache-Control: no-cache < Cache-Control: must-revalidate < Expires: -1 < Content-Length: 0 < X-Content-Type-Options: nosniff < X-XSS-Protection: 1; mode=block < Content-Security-Policy: default-src 'self' 'unsafe-inline' 'unsafe-eval' data: blob:; img-src 'self' data: http://127.4.1.1 http://127.4.2.1 < Connection: close < * Closing connection #0 * SSLv3, TLS alert, Client hello (1): } [data not shown]The issue was related to RPM processes being stuck on the guest. I ran the above curl command (per F5 support) from both BIG-IQ and the guest itself and the results were the same. Running a filesystems check and rebooting the guest fixed the issue. Thanks Lucy.
hoolioCirrostratus
CirrostratusHi Claire,
I think the main cause of that error is that a redirect has already been triggered for that request/response. Do you have another iRule on the same VIP which could be redirecting before this one runs?
Else, can you save the request details in HTTP_REQUEST and log them in each response before doing the header updates? This might give you more information on when the TCL error is happening.
Aaron
- hoolioThat should work fine. If the web app uses absolute references to https:// in response headers or content, you might need to rewrite them to http://. But give it a shot first and see if it works as is.
Aaron 
fita_30888Nimbostratus
Cheers for the reassurance! The confguide says "re-encrypting a decrypted request" so I was in doubts. As for the replace would an iRule with switch do the job?
thanks- hoolioRe-encrypting a decrypted request is the most common (not not only) use case for server SSL. If you need to rewrite the response headers, you could use 'HTTP::header replace'. For response content, you could use a blank stream profile and a STREAM::expression iRule.
Here are a few examples:
http://devcentral.f5.com/wiki/default.aspx/iRules/RewriteHTTPRedirectHostname.htmlwhen HTTP_RESPONSE { Check if server response is a redirect if { [HTTP::header is_redirect]} { Log original and updated values log local0. "Original Location header value: [HTTP::header value Location],\ updated: [string map -nocase "https:// http://" [HTTP::header value Location]]" Do the update, replacing https:// with http:// HTTP::header replace Location [string map -nocase "https:// http://" [HTTP::header value Location]] } }
And for payload rewriting:
http://devcentral.f5.com/wiki/default.aspx/iRules/STREAM__expression.htmlwhen HTTP_RESPONSE { Disable the stream filter by default STREAM::disable Check if response type is text if {[HTTP::header value Content-Type] contains "text"}{ Replace https:// with http:// STREAM::expression "@https://@http://@" Enable the stream filter for this response only STREAM::enable } }
As the payload size would change for the stream iRule rewrite, you'll need to set the HTTP profile option for chunking to rechunk.
Again, I'd suggest you try the scenario without iRules to start with. It's quite possible you won't need any iRules.
Aaron - fita_30888Hello again,
we have tested it but, we've only got success when the virtual address is on :443. As the requests are coming on :80 I was thinking of inserting the port to request via something like this:
when HTTP_REQUEST {
if { not [HTTP::host] contains ":" } {
HTTP::header replace Host "[HTTP::host] : 443"
}
}
I'm trying to replace the :80 with :443 in this irule.
cheers - hoolioWhat fails when the VS is on port 80? Does the client get any response? Can you capture a tcpdump on LTM and use a browser plugin like HttpFox for FF or Fiddler for IE to see what's happening?
Aaron - fita_30888Hi,
I'll have it retested it later today get the tcpdump and look into http headers, as i'm un. when the VIP is on 80 and pool is on 443, than the client gets no response at all. it just opens tcp session, waits and eventually timesout. when they set the pool to 80 and vip with no serverside ssl they got through. and when they set the vip on 443 pool on 443 they get to the page. the LTM is running 9.4.x - fita_30888Aaron,
they had port translation disable on the VIP after enabling it everything works fine!
thanks for you help!
![\"F5](\"https://www.f5.com/content/dam/f5/f5-logo.svg\"){kind=logo}
