Cannot connect to iLO3 remote console on a hosted ProLiant DL120 G7

[JeremyJust]

    Hi all,

  I'm having a hard time connecting to iLO3 Integrated Remote console on a ProLiant DL120 G7 (firmware 1.26 Aug 26 2011) with advanced license,  that I rent from a hosting provider (online.net).

  When I launch the remote console from the web host, a java process is spawn, that use a lot of CPU during a few minutes, I have to accept several java security warnings, and then... nothing!
  From another computer, I happen to get a Java window but also get a pop-up « Connection timed out. Your browser session may have timed out. ».

  I've tried various combinations of:
 - Gentoo Linux 64 bits / Gentoo Linux 64 bits / Windows XP 32bits
 - OpenJDK 1.6 (icedtea 6.1.11.1) / Oracle JDK 1.7 (oracle-jdk-bin 1.7.0.3)
 - Firefox 10.0.4 / Chromium 19.0.1084.52 / IE 8

  I've performed a nmap scan on the iLO host. The ports 22, 80 and 443 are reachable, but when I try to connect through SSH  to the host, I get no answer.


  I'm tired of trying to guess what can be wrong. How could I establish an enlightened diagnostic?
  I've read somewhere that it was possible to download the Jar file from the host, and then run it from command-line, but I can't find the jar... Could anybody help me?

  Do you have any other suggestion to use the iLO console from my Linux box?

  Thanks for your help!

[Oscar A. Perez]

Can you access the iLO3 webGUI?  If so, go to the Diagnostic page and click on the iLO3 "Reset" button.  After than please upgrade your firmware to version 1.28

For iLO3 Remote Console, in addition to port 443 (initial handshake), you need to open TCP port 17990 in the firewall.

[JeremyJust]

Yes, I can access the Web GUI, and I've tried to reset the iLO module before reconnecting. But I'm not allowed to upgrade the firmware by myself, and the provider who rent the server to me is not willing to upgrade it.

The provider technical support keeps answering « that works for me ». I've tried literally dozens of configurations:

 - several Windows, Solaris 5.9, Gentoo Linux, Ubuntu Linux, CentOS, MacOS,

 - four different networks, most of them fully open outbound,

 - Firefox, Chrome, Internet Explorer, Safari,

 - JVM 1.6.xx and 1.7.xx from Sun (including OpenJDK), Oracle, Apple, IBM.

Most of those configurations fails, either with an explicit timeout pop-up window, or with a Java exception (java log available if needed). I've only succeeded using two of them, from two locations connected through the same internet access provider (and the exact same software configuration fails from everywhere else). So I guess there is something with the network.

Are there some undocumented network requirements? I've stored the tcpdump traces, and should be able to compare them with some from unsuccessful configurations, but any hint could save me some time...

Anything with UDP traffic? Could packet normalization get in the way?...

Thank for your help!

[Oscar A. Perez]

I would like to see the Java log after it fails to connect. Is that possible?

[JeremyJust]

I can only send you the last exception on a public forum. I've just sent you the whole log in a private message.

In the meantime, I've used "lsof" on a running iLO remote console, and I've observed that it maintains IPv6 connections with the iLO module (on ports 443, 17990 and 17988, as far as I remember). All other processes running on this machine use IPv4.

Moreover, I think the two networks from which the console works are the only ones that could support IPv6 all the way. I'm almost sure that all the others networks from which I've tried to connect have IPv4-only appliances somewhere in the middle.

Is IPv6 a known requirement of iLO remote console? Should I investigate further in this direction?

[Oscar A. Perez]

iLO3 doesn't support IPv6 yet.

I'm checking the logs

[JeremyJust]

    Hi all,

  I've investigated further, and tried a few different network configurations on a router I manage (running OpenBSD), carefully reading the router logs.

  It appears that the ports 17990 and 17988 were responsible for my failed connections... Even when Firebind (http://www.firebind.com/) told me they were open, traffic was blocked. I add a few Packet Filter rules, and everything is OK. This explanation sounds applicable for all the networks I tried to connect from.

  Thank you for your help! I'm sorry I've wasted your time, as the problem was coming from local network configurations!