Unsolved
4 Posts
0
1076
March 31st, 2023 05:00
Connecting via NAT using public IP and/or FQDN is completely impossible.
We provide access to iDRAC via NAT. We create a connection to the public IP from the specified user IP. For iDRAC9 version less than 6.00 everything worked fine. After updating to 6.00.30. there was a problem with a bad request, which solved it:
"racadm set idrac.webserver.HostHeaderCheck 0"
After updating to versions 6.10.00 and 6.10.30, another problem appeared. The virtual console starts with the local IP address assigned to the iDRAC. Connecting via NAT using public IP and/or FQDN is completely impossible.
No Events found!
markusikkk
4 Posts
0
June 6th, 2023 08:00
Any suggestions on this topic?
atafm2
2 Intern
•
89 Posts
0
June 6th, 2023 12:00
roll back to 6.00?
what i do instead is put all my idrac on their own network along with an ubuntu or windows VM.
I only allow NTP, 443, and DNS ports into the network.
I remote connect to that VM using TeamViewer or similar.
I use the VM to connect to and manage the idracs.
I think exposing idrac directly to the internet using NAT is a very BAD idea. and a huge security risk. I would recommend against that and instead use a setup like mine.
markusikkk
4 Posts
0
June 13th, 2023 07:00
@atafm2
We create NAT only for the indicated source IP address. We do not issue access publicly
Anonymous
12 Elder
•
274.2K Posts
0
June 13th, 2023 09:00
Instead of rolling back to version 6.00, I suggest implementing a different approach. In my case, I create a separate network for all my iDRAC devices and connect them with an Ubuntu or Windows VM. This network only allows specific ports such as NTP, 443, and DNS. To manage the iDRACs, I remotely connect to the VM using TeamViewer or a similar tool.
In my opinion, exposing iDRAC directly to the internet through NAT is highly risky and a major security concern. I strongly discourage this practice and recommend opting for a setup like mine to enhance security. I suggest you to read this post by click here.