Page 1 of 1

WebSphere / VirtualBox problem

Posted: 17. Sep 2008, 10:07
by vainov
I installed WebSphere Portal 6.1 (WPS) in a VirtualBox (WinXp host, CentOS 5.2 client).
Now I have problems connecting to this WPS instance from a browser running in the host computer.
The problem seems to be that the HTTP call do not reach WPS properly, or WPS can not find its way back to the browser.
FYI: DNS lookups work from inside the client. I have tested it using the nslookup command.

I use NAT networking, and have modified it with the following:
(NB! Port 10040 is the default for WPS HTTP connections, and Port 10041 for the HTTPS equivivalent)

VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/Protocol" TCP
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/GuestPort" 22
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestssh/HostPort" 2222
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestwps/Protocol" TCP
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestwps/GuestPort" 10040
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestwps/HostPort" 1040
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestweb/Protocol" TCP
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestweb/GuestPort" 10041
VBoxManage setextradata "WPS61" "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guestweb/HostPort" 1041


SSH works fine, so I know that my configuration "sticks". It is only HTTP that fails.
I use Firefox 3 and try to connect using the following URL:

http://hostname:1040/wps/myportal


Any ideas?

PS! I'm not a seasoned VirtualBox user. However, I have very extensive experience with Xen and VMWare. DS!

Continued

Posted: 17. Sep 2008, 15:56
by vainov
I now have started Apache and attempted the same configuration for port 80, with identical result.
I.e. when I issue the following in a command shell in the client:
telnet localhost 80
or
wget http://localhost
I get a meaningful response.
However, if I do the same from a command window on the host I don't get any response at all.
Using tcpdump on the client I can see that the packets are delivered to the virtual machine, but they don't seem to arrive at the destination of the listening application.

Posted: 17. Sep 2008, 19:27
by Sasquatch
If you only need this kind of communication from the Host to the Guest, try Host Interface. You don't have to create a bridge, just follow the other steps mentioned in the manual. You have to set a static IP on both the Host and Guest side of the network. Don't use the same IP, but keep them in the same range. E.g. 192.168.4.1 for the Host and 192.168.4.2 for the Guest with a netmask of 255.255.255.0.

Posted: 17. Sep 2008, 19:34
by TerryE
You are mapping host:10040 to guest:1040, so to connect to the webshere, you need to use //Terry

Sorry, No!

Posted: 18. Sep 2008, 14:25
by vainov
I have mapped host port 1040 to client port 10040, so the call should be
http://hostname:1040
which is forwarded to client's port no 10040.

As I mentioned, it is no longer relevant; it was just an experiment. Nowadays I mapp 10040 to 10040 etc.

btw

Posted: 18. Sep 2008, 14:28
by vainov
BTW: In order to insulate the cause of the problem better I have started to experiment with Apache.
Here, I map Host port 10030 to client port 80. The result is the same.
I have also disabled SELinux entirely (previously it was in permissive mode). Still no improvement.

Posted: 18. Sep 2008, 15:39
by TerryE
Re mapping, yes your right: I misread your NAT maps. One thing that you do need to be careful with -- especially with Web 2.0 technologies -- is "under the cover" hrefs. As long as all references are site relative, e.g. <a ... href="somePagePath.html" ... > then the browser in effect prefixes the current site and socket to the reference when resolving it in HTTP. Hence in this case this will become in your example http://host:1040/somePagePath.html which will then get mapped my NAT to http://guest:10040/somePagePath.html and all works. Problems can occur because some CMS and framework deprecate relative addressing on security grounds (they make it easier for plishers to layer over site) and the generate hrefs which embed the site and port, e.g. <a ... href="http://guest:10040/somePagePath.html" ... >. But when the client browser resolves this, it of course fails.

Where this gets difficult to detect is when the site is 90% relative and the absolute bits are buried down in some web 2.0 callbacks which just fail or timeout silently. I've been burnt by this one myself. The only effective solution is either to configure HIF or sometimes the package can allow you to override the site:port prefix.

Problem solved

Posted: 24. Sep 2008, 14:32
by vainov
This was a complete bummer!
The problem turned out to be CentOS! It arrived out-of-the-box with IPTables enabled. The default rules prevented outside users from connecting to the OS.
Removing
/etc/sysconfig/iptables
and
/etc/sysconfig/ip6tables
solved the problem.
Sorry about all the excitement!