When I first began this WordPress based blog, I had it set in my mind to run this one in Ubuntu / Apache, pending experiments with Docker.
And I had planned the use of IIS Reverse Proxy.
Initially the IIS Reverse Proxy lead to great difficulties and it turned out my aged installation on my main (at the time) Windows 8.1 based IIS Server had become subtly corrupted, causing behaviour that didn’t meet what I expected from tutorials in an exasperating and confusing way. That forced me to make a new installation – eventually becoming my post-pfSense DMZ point of entry for https.
Back then (end-January 2017) I didn’t have pfSense. My organically grown network with limited BT Business Hub 3, using my 5 public IP addresses, had become progressively tangled over time with constant experimentation and profligate virtual machines and different hardware.
Setting-up the blog, I had in mind that I wanted it to be a critical document repository for my set-up, available completely independently of the internet, using its server/domain name as the url, also set in WordPress settings, and to use rewrite rules in .htaccess and on the IIS reverse proxy for headers and content, to switch between whatever external URI I gave it and the internal one. This proved to be hard work.
I wanted something I could depend on for documentation, regardless of whether the internet or my router/BT Business Hub was working correctly and without having to remember to set-up host files etc. but now I think I was just foolish. (The way I went about it).
Now, with pfSense, I use split-DNS. Also I just set host files differently on certain machines; I’ve reset WordPress’s URL settings to simply be the blog URL, and also .htaccess on Apache to not mess with the header or content for the URL. Just in case there are any deep references to the internal domain left in any posts etc. I’m leaving my IIS Reverse Proxy rule on to change that internal name to the external URL.