Hi Folks and a very happy new year to you all! :)
Firstly, please note that I am merely a home user (so not paying my way, here) and that that this is a very low priority question! It's just puzzling the heck out of me and I wondered if anyone had any ideas on why it doesn't work (in other words, I'm mostly just asking this to help enhance my understanding)?
I've been using UTM's WAF to reverse proxy an Icecast stream (so both an http page and an audio stream*) and I use another virtual server instance to reverse proxy an Apache page (also running on the same Raspberry Pi) and using encrypt and redirect (using a LE cert) and of course, it all works flawlessly.
Mostly just as an experiment (though it could be useful to have it enable-able) I also tried setting up a reverse proxy instance of my UniFi server (which is running on a different Raspberry Pi) and with UniFi already having an https interface, I configured the virtual and real Webservers as is shown below:
From memory, I initially had the re-write html and re-write cookies ticked and using https://ddns:9666 showed the UniFi log-in page, so initially it all looked to be working, but the page also had a couple of websocket error message pop-ups, so having spotted the new feature in the site path routing settings, I elected to enable websocket pass-through to see if that would remove the pop-up error messages.
This is where it almost gets quite interesting as after enabling that websocket pass-through feature, the browser now showed just a plain white page, then after disabling the websocket pass-through feature, the 'fault' remained (plain white page). Of course, I have tried several browsers (with cleared caches) and things like toggling the re-write html and re-write cookies options, but no matter what I have tried, all I can now see is a blank page.
Assuming it was something that had been corrupted on the Pi, I removed then re-installed UniFi, and access by using https://ddns:port showed the initial UniFi set-up page (so I thought I'd fixed things). I then set up the UniFI basics (password, language and region) and when it got to the stage where the log-in screen should appear, back appears my blank screen.
The Pi is on its own VLAN, but I have a firewall route to it, so I can access it LAN side (https://192.168.1.7:port) and after accepting the self-signed cert, the login page shows perfectly in the browser, so my next step was to view the source code from both the https//192.168.1.7:port (log in screen showing as expected) and https://ddns:port (plain white screen) and though I've yet to go through it all (using diff on large html files - which are full of containers - is not an easy task), I have already noticed that whilst the first section on each is identical (other than the <!DOCTYPE html> being on a separate line) and is shown below, I noticed that there are a few subtle differences in the lines following that first section.
First section:
<!DOCTYPE html><html lang="en" ng-controller="ManageController as manageCtrl" ng-strict-di><head><meta charset="utf-8"><title ng-bind="manageCtrl.system.getName() || manageCtrl.system.getHostname() || 'UniFi Network'">UniFi Network</title><meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no" unifi-prevent-focus-zoom><meta name="apple-itunes-app" content="app-id=1057750338"><base href="/manage/"><link rel="apple-touch-icon-precomposed" href="images/favicons/favicon-152.png?v=2"><meta name="msapplication-TileColor" content="#0193d7"><meta name="msapplication-TileImage" content="images/favicons/favicon-144.png?v=2"><link rel="apple-touch-icon-precomposed" sizes="152x152" href="images/favicons/favicon-152.png?v=2"><link rel="apple-touch-icon-precomposed" sizes="144x144" href="images/favicons/favicon-144.png?v=2"><link rel="apple-touch-icon-precomposed" sizes="120x120" href="images/favicons/favicon-120.png?v=2"><link rel="apple-touch-icon-precomposed" sizes="72x72" href="images/favicons/favicon-72.png?v=2"><link rel="apple-touch-icon-precomposed" href="images/favicons/favicon-57.png?v=2"><link rel="icon" href="images/favicons/favicon-32.png?v=2" sizes="32x32"><script src="config/config.v5.12.35.0.js"></script><script type="text/javascript">window.unifiConfig.version = '5.12.35.0';
When using 192.168 access, the above is followed by:
</script><script src="js/initial.v5.12.35.0.js"></script><script src="js/components.v5.12.35.0.js" defer></script><script src="js/base.v5.12.35.0.js" defer></script><script src="js/main.manage.v5.12.35.0.js" defer></script><style>
When using the reverse proxy to access it, it is instead followed by the below:
</script><script src="js/initial.v5.12.35.0.js"></script><script src="js/components.v5.12.35.0.js" defer="defer"></script><script src="js/base.v5.12.35.0.js" defer="defer"></script><script src="js/main.manage.v5.12.35.0.js" defer="defer"></script><style>
I use notepad to build my web pages and I have zero knowledge of JS, so I'm just assuming that the above variants of the same, but if not, could that be what's causing the page not to show correctly (and if so, I wonder what's causing that to happen)?
Or - and I suspect this to be a more likely explanation - am I not understanding something that's really basic (and obvious to everyone else) about what can and cannot be done when attempting to reverse proxy on an https page?
Kind regards,
Briain
*The audio stream is to facilitate other radio amateurs' monitoring an audio from a 10 GHz beacon receiver, located at my house.
This thread was automatically locked due to age.
