To be honest, I don’t exactly know too much about Big-IP, but I’ve come across someone who use it. They terminate HTTPS in Big-IP and WordPress runs on plain HTTP on port 80 on the backend nodes. By default, this makes WordPress confused, so you can’t login to the WordPress dashboard.

Most load balancers and reverse proxies I’ve come across sets the HTTP header X-Forwarded-Proto, but Big-IP did not. Instead, we had to edit the profile configuration in Big-IP (under Profiles : Services : HTTP) and activate the Request Header Insert parameter WL-Proxy-SSL: true. Now we had access to this header via $_SERVER['HTTP_WL_PROXY_SSL'] in PHP, and could check it to see if the client actually was on a HTTPS connection and could instruct WordPress accordingly.

To clear up the misunderstanding for  WordPress, we prepended wp-config.php with this snippet:

if ( isset( $_SERVER['HTTP_WL_PROXY_SSL'] ) && 'true' == $_SERVER['HTTP_WL_PROXY_SSL'] ) {
    $_SERVER['HTTPS'] = 'on';

$scheme = 'http';
if ( isset( $_SERVER['HTTPS'] ) && 'on' == strtolower( $_SERVER['HTTPS'] ) ) {
    $scheme = 'https';

define( 'WP_SITEURL', $scheme . '://' . $_SERVER['HTTP_HOST'] );
define( 'WP_HOME', $scheme . '://' . $_SERVER['HTTP_HOST'] );

Depending on your need, you could hardcode the hostname instead of using the Host HTTP header.