13 Posts
0
1393
Why I cannot access iDRAC9 remotely?
I have a Dell PowerEdge T350 with an iDRAC9 Basic. The server is connected to a switch which is connected to a router upstream which is connected to the internet. Very simple. Both the server's NIC1 is connected to the switch and also the iDRAC's own UTP LAN card. I enabled the iDRAC and I can access the web GUI from another host connected to the same switch (a.k.a. intranet).
Both LAN interfaces of the server have static intranet IPs configured (on the 192.168.1.x range) and not DHCP-d, since the port translations on the router we better have a fixed IP. I configured the port translations on the router so two service could be accessed remotely: RDP and the iDRAC. The RDP is the server OS itself.
Here comes the interesting part:
- I can access the server OS with RDP via the intranet
- I can access the server OS with RDP remotely
- I can access the iDRAC web GUI via the intranet
- I CANNOT access the iDRAC web GUI remotely
I configured the iDRAC port redirection (or we can call it firewall pin hole) the same way as I did with the RDP. Although the RDP needs both TCP and UDP 3389 port redirection. The iDRAC only needs TCP 443 port redirect.
Questions:
- Is there any switch or configuration option on the iDRAC which prevents intranet access by default? (Although there an address translation / NAT going on by the router, so this question might not even make sense?)
- The router in question is an PACE 5268AC FXN. I cannot find anything in the manual which would indicate that it'd allow 3389 (or also 3390 because I also pin holed another machine's RDP) redirection but would fail with HTTPS. I don't see anything useful in the firewall log which would help. It seems that somehow the intranet 443 incoming packets don't even reach the router? I don't get it.
- I also tried a 33443 -> 443 and other type of redirections instead of 443 -> 443, but that didn't work either.
- I also add that the SSL cert of the iDRAC is a dud (not valid), but it seems that the thing fails at some earlier stage. The ISP is AT&T.
Related ServerFault issue: https://serverfault.com/questions/1129118/why-i-cannot-access-idrac9-remotely
tocsa
13 Posts
0
April 20th, 2023 19:00
Hey Joey C and other Dell professionals. I double checked my iDRAC network settings, the gateway was proper (192.168.1.254). I also searched fro and verified that the iDRAC can ping the gateway ("racadmin ping 192.168.1.254" when I logged into the iDRAC web GUI on the intranet). I also checked the port pinhole configuration of the router, which seemed also fine. I tried to access the Web GUI remotely a few times and I verified that the router's firewall logs didn't yeet those packets and recognized as pinhole access.
Not sure what changed, but maybe my browser tries http protocol by default when it sees an IP address (I'm accessing the iDRAc remotely only with a static IP address, no DNS name), when I manually put https protocol, I got to an error message instead of a timeout:
"Bad Request
Your browser sent a request that this server could not understand
Additionally, a 400 Bad Request error was encountered while trying to use an ErrorDocument to handle file request."
This was both with Firefox and Chromium based browsers. Then I search for this specific error message and in a Knowledge Base article I found a solution which helped: HTTP/HTTPS FQDN Connection Failures On iDRAC9 firmware version 5.10.00.00 | Dell US
"
Cause
Resolution
By default, iDRAC9 will check the HTTP / HTTPS Host Header and compare to the defined 'DNSRacName' and 'DNSDomainName'. When the values do not match, the iDRAC will refuse the HTTP / HTTPS connection. In iDRAC9 5.10.00.00, this Host Header enforcement can be disabled with the following RACADM command.
#Disable host header checkracadm set idrac.webserver.HostHeaderCheck 0
"
Now I wonder if this poses any security risk. We access the iDRAC from not fixed IPs and address it with an IP address. I can only think of a REST Client only which would inject required HTTP Headers. But at least I can access the iDRAC web GUI now.
tocsa
13 Posts
0
April 19th, 2023 15:00
Note: I know that exposing iDRAC or RDP remotely makes them more exploitable. However as remote management as a phrase suggests (nomen est omen) I must manage it remotely because the premises are remote and the test box is subjected to brown-outs especially during the summer. Se also my comments at Server Fault.
Kilo7
4 Posts
0
April 19th, 2023 23:00
I am having a similar issue. I update the iDRAC firmware from v4 to v6.10.30.20. With iDRAC firmware v4, I was able to access it remotely using port 443 (port forward). Now after the upgrade to v6, I can no longer access iDRAC remotely using port 443. I know iDRAC is up and running as I can access it locally (port 80).
DELL-Joey C
Moderator
Moderator
•
3.4K Posts
0
April 20th, 2023 00:00
Hi.
(This is for both @Kilo7 and @tocsa)
What error was prompted in the browser when you tried accessing to the IP? @tocsa, what is your iDRAC version? Just to check, can you confirm port 443 is not being used for any other applications?
Kilo7
4 Posts
0
April 20th, 2023 07:00
Hi Joey. The webpage no longer responds (no error message) when I go to https://xxx.xxx.xxx.xxx. It was working last night using firmware v4. I did the upgrade remotely, then tried logging back in once the update was complete and the same web address stopped responding.
I've also tired https://xxx.xxx.xxx.xxx:443 and xxx.xxx.xxx.xxx:443.
If I RDP into Windows, which is installed on the hardware, open the browser and type in the local iDRAC IP (192.168.1.31) it works. So we know iDRAC is working and responding.
One thing I have not tired is changing the port from 443 to something else and updating the port forward rules in the router to reflect the new port number.
DELL-Chris H
Moderator
Moderator
•
8.8K Posts
0
April 20th, 2023 07:00
Since the issue worked under the previous firmware, and you confirmed the idrac is in fact accessible (locally), what I would start with is trying another browser or clearing the browser data on the one you were using. Also, have you tried restarting the idrac again since the update?
Lastly, regarding the port, with Https 443 is the only option, if you were to try http it would be port 80.
Kilo7
4 Posts
0
April 20th, 2023 23:00
Thanks for finding a solution. This is the error that I received. I wonder if there is a way to fix this without using the RACADM CLI.
tocsa
13 Posts
0
April 21st, 2023 11:00
Just for the record, my iDRAC Firmware version is 6.10.30.00 (Build 29), iDRAC Settings version 5.00.00.10
Kilo7
4 Posts
0
May 29th, 2023 22:00
For reference, iDRAC firmware version 5.00.20.00 solves the issue of remote access via port forwarding. I have a PowerEdge R340. It shipped with iDRAC firmware 4.10.10.10. Remote access to the iDRAC dashboard worked without issue. Upgrading to firmware version 6.10.30.20, broke remote access (400 Bad Request Error). Downgrading to firmware version 5.00.20.00 allows for remote access and everything is working again.
I would suggest not upgrading past 5.00.20.00 if you need remote access to iDRAC via port forwarding.
Furthermore, I would not mark this thread as solved, since version 6.10.XX.XX breaks this feature.
tocsa
13 Posts
0
May 30th, 2023 00:00
I got v6+ iDRAC firmware version from the get go and I'm most definitely able to access the iDRAC remotely. Given I applied the racadm command I described.