Wordpress and F5 WAF - Infinite loop due to SSL

554 Views Asked by At

I have a wordpress website on https and it was working fine without the implementation of F5 WAF on the server. But as soon as the WAF is enabled, the website goes onto an infinite loop.

After debugging I found that the wordpress is doing 301 redirection to HTTPS and WAF is doing the same. As a result, I have stopped wordpress from doing 301 redirection to HTTPS which fixes the infinite loop problem (as wordpress isn't doing HTTPS redirections anymore). But after doing this, all the asset files that the theme / wordpress loads are getting blocked as they are not on HTTPS anymore.

Any idea how this could be fixed?

Following is my .htaccess code:

# BEGIN WordPress
# The directives (lines) between "BEGIN WordPress" and "END WordPress" are
# dynamically generated, and should only be modified via WordPress filters.
# Any changes to the directives between these markers will be overwritten.
<IfModule mod_rewrite.c>
RewriteEngine On
# RewriteCond %{HTTPS} off
# RewriteCond %{HTTP:X-Forwarded-Proto} =http
# RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

PS: Is there any way to make all the theme assets load through relative paths without base URL? I am using Avada theme.

2

There are 2 best solutions below

0
On BEST ANSWER

This is happening because you have the F5 offloading SSL and going clear text to the WordPress server. There are a few ways to fix this but the easiest way is to re-encrypt back to your Wordpress server. So just change the pool member to be HTTPS/443 and add a “serverssl” profile to the virtual server. Let me know if you need more detail than that.

0
On

By far the easiest way to fix this would be to add a serverssl profile to the virtual server on the F5 WAF to cause it to re-encrypt before sending traffic to Wordpress. This way the rewrite condition (in the original config before you modified it) would not be invoked.

This also has the benefit of improving the overall security of the application.