Score:2

Server

Why I cannot access iDRAC9 remotely?

Csaba Toth

4/19/24, 9:27 PM

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.

For the record my iDRAC Firmware version is 6.10.30.00 (Build 29), iDRAC Settings version 5.00.00.10

1484

2 + 6

rdp

router

drac

redirection

Peter Zhabin

4/19/24, 9:45 PM

Do you have a default gateway configured in iDRAC LAN configuration? There's also a setting in iDRAC security that allows to restrict access to iDRAC to a certain IP/subnet. The idea of exposing iDRAC interface to the public internet unrestricted is a bad practice though, next question you'll be asking is why you've been locked out of iDRAC account, these are bruteforced at a scale..

Csaba Toth

4/19/24, 9:57 PM

@PeterZhabin I believe I have the gateway configured, which was one field when I configured the static IP along with netmask, but I'll double check that. I'm iffy about exposing iDRAC, but the sole purpose of remote management is - nomen est omen - to manage it remotely, so when the server goes down bc of brown-outs I can restart it. The server is not critical and used only for tests, I'd never expose a production server this way. I may introduce VPN or something else later possibly.

Csaba Toth

4/19/24, 10:00 PM

If it was up to me BTW I'd have this box in the cloud, at least IaaS but rather PaaS, but my client insists to have an on-prem test server, which is subjected to brown-outs especially during the summer months. The bottom line is I need both iDRAC and RDP because the premise is remote to both me and my client.

user1686

4/20/24, 6:25 AM

If that's the case, I would suggest also having an on-prem VPN endpoint, e.g. a tiny Mikrotik hEX, that would allow you put iDRAC in its own subnet and to wireguard/ipsec into the location remotely (potentially even without relying on port-forwards at all if you can have the router connect out to your location instead).

user1686

4/20/24, 6:27 AM

To clarify though, although there is indeed "NAT going on", a port-forwarding rule is _only_ DNAT – it only translates the destination, it does nothing to the _source_ IP address which is still the remote client system's public address.

Prem

4/20/24, 8:31 AM

IDRAC HTTPS Port is configurable , you can try with a Different Port to check where it is getting blocked. Can you Connect over SSH ? Can you Connect over HTTP ? These things will give "Debug Data" about where the Issue lies.

Score:2

Server

Csaba Toth

4/21/24, 2:04 AM

I double checked my iDRAC network settings, the gateway was proper (192.168.1.254). I also searched for 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.000

Cause The webserver in iDRAC9 firmware version 5.10.00.00 enforces an HTTP / HTTPS Host Header check by default. 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 check
racadm 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.

+ 0

Score:0

Server

Wichard Hartes

8/28/24, 8:36 AM

A solution is to use the IP address instead of the FQDN. Then it does work.

+ 1

Csaba Toth

8/29/24, 5:03 AM

I was using ip addresses everywhere from the get go. First intranet, and once I got this issue resolved as I described I also use ip address from external access. This way I also rule out any DNS quirks

Elon Musk

I sit in a Tesla and translated this thread with Ai:

EN: Why I cannot access iDRAC9 remotely?

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.