3

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:

  1. I can access the server OS with RDP via the intranet
  2. I can access the server OS with RDP remotely
  3. I can access the iDRAC web GUI via the intranet
  4. 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:

  1. 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?)
  2. 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.
  3. I also tried a 33443 -> 443 and other type of redirections instead of 443 -> 443, but that didn't work either.
  4. 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

Improve this question
6
  • 3
    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..
    – Peter Zhabin
    Apr 19 at 21:45
  • @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
    Apr 19 at 21:57
  • 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.
    – Csaba Toth
    Apr 19 at 22:00
  • 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).
    – u1686_grawity
    Apr 20 at 6:25
  • 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.
    – u1686_grawity
    Apr 20 at 6:27

2 Answers 2

Reset to default
3

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.

Improve this answer
1

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

Improve this answer
1
  • 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
    – Csaba Toth
    Aug 29 at 5:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .