@htb I’ve had a breakthrough. Some extra details first: the problematic box as I’ve said has two different interfaces. egiga0 (which also had the network routing) is on my DMZ (192.168.1.x), whereas egiga1 was on LAN (192.168.0.x).
My LAN is not allowed to connect the net. It can connect only through a URL filtering proxy residing on the gateway. DMZ hosts can connect to the internet.
As I’ve described in my previous posts I had brought the egiga1 interface to work in active failover mode, just to reset things in networking, but after a reboot I was no longer able to connect at all to the box over HTTP.
Tried whatever I could over SSH: compared /etc settings between my two NAS boxes (the second resides strickly in the LAN) but to avail. The LAN-only box did allow me to connect over plain http, whereas the external one did not. And both of them I could not connect over https.
My client pc is on the LAN (192.168.0) and as I said all my attempts to connect over http/https to the box failed miserably.
Then I decided to try accessing the DMZ ip from a system also in DMZ. And this time it worked! Specifically, I was presented with the login page, but the URL was not the DMZ ip of the system, but a special of the following form
device-local-anidofsomesort.remotewd.com resolves to the (private) ip of the DMZ interface! I presume that the device registers itself (if it has internet access) to remotewd.com to accomplish that. I presume that the advantage of this hack is that a home user can connect to his box using a reliable certificate. The disadvantage is that a user behind a protected network (like the other box residing in my lan) can not access the box over https (whereas a self-signed certificate would do the job nicely)!
And that’s issue 1.
Issue 2: in doing this, WD gets information about my network topology (DMZ address/subnet). This is outrageous, especially considering that (a) our environment is striving for GDPR compliance, (b) I’ve opted out of all call-home communication with WD!!!. I can not stress hard enough how dangerous is for WD to gather that sort of information. If you are going to provide this “facility” have the user opt-in for it, instead off opting-out or, even worse, not offering any workaround like self-signed certificates!
Issue 3 possibly explains why I could not connect to the problematic box at all. I guess that the box had registered itself alright with its special device-local-anidofsomesort.remotewd.com resolving to a 192.168.1.14 address. This did not explain why I was not able to connect to it from the LAN side (192.168.0).
I did stumble into some older (5.07.118) release notes, stating the following:
Modified IP address filter of web dashboard to allow access from computer within the same subnet if user is using IP address that are not within the private IP ranges defined by RFC1918 of the Internet Engineering Task force
If this modification blocks my lan pc from viewing the DMZ system, then again it’s clearly a bug, since this “functionality” should not affect users whose ip addresses are clearly in the RFC1918 IP ranges!
Issue 4 related to the issues above. On my other, LAN-only box I can connect to the box only via http. No https at all. Possible cause: the box can not connect to the internet to get this pseudo-DNS (direct connection to inet from LAN is allowed only through a filtering proxy; which the box does not understand). Again, we need some way to either disable https completely (dangerous) or allow self-signed certificates (better)!
PS: I’m now having a two day downtime. Noone even cared to address my support ticket. Yesterday after waiting 30 minutes for chat support, when my turn came the chat was dropped for heaven’s sake/
I’m really furious with WD for this level of incompetence. They are definitely going to be ruled out for future procurement. In the price range, I’ll definitely stick with QNAP/Synology.