host networking: host --> guest port forwarding

[curt504a]

Host is XP, guest is XP, hostneworking for security and to keep the guest from routing off the host box. I want one or more ports on the host accessible on the guest locally (port forwarding from the host to the guest).

I've read the desktop networking chapters and searched forums..

Thanks for any tips!

curt

[Peter_vm]

Where are planning to access this forwarded service from ?

Normally you would use NAT (VMnet8) setting for guest.

[curt504a]

I want an application in the guest to see select ports local to the guest that are listened to in the host as if they where local. IE port forwarding from the host to the guest. Oposite of what I've read for NAT where external apps access listened to ports in the guest.

tnx curt

[Peter_vm]

?? I'm not getting it. Please provide some sort of example. Where is the service located and how client is planning to communicate with it.

[curt504a]

There's a webserver in the host on port 80.

Theres an app in the guest that's hard wired to only open localhost ports needs to access localhost:80.

Normally the app in the client would run in the host, but for other reasons I'm running this app in a VM and now need to port forward from the host into the client, port 80 so the app in the client can open localhost:80.

Yes this is odd or opposite of most scenarios but I feel this is another scenario of modularizing a large host into separate VMs and making the network port space flat as if the apps in the VMs are still in the host's localhost port space.

This is windows in the host and guest so running sshd in the host and ssh clients doing port forwarding from the host in each VM is doable but not as out of the box as with linux in both places. I'm hoping VMware has similar port forwarding capabilies into the client built in.

Thanks, curt

[Peter_vm]

Change "localhost" 127.0.0.1 in guest hosts file to ipaddress of your host?

[curt504a]

Ha! Good one! What if the app is hard coded to open 127.0.0.1? Sorry for the odd issue here. The purpose of putting this app in a VM and host networking is for extreme isolation and protection from virus etc making out bound network connections except to selected ports, which is where my idea of doing selected port forwarding from the host to the client came in.

curt

[Peter_vm]

Ha! Good one! What if the app is hard coded to open 127.0.0.1? Sorry for the odd issue here. The purpose of putting this app in a VM and host networking is for extreme isolation and protection from virus etc making out bound network connections except to selected ports, which is where my idea of doing selected port forwarding from the host to the client came in.

Then I would just scrap that application. I have never heard about that cumbersome approach. There are standard methods to deal with network security (firewalls, NAT), this one is definitely odd.

[glibik]

Seems, to me, like a task for the infamous XP internet connection sharing.

[PJN]

Ha! Good one! What if the app is hard coded to open 127.0.0.1? Sorry for the odd issue here. The purpose of putting this app in a VM and host networking is for extreme isolation and protection from virus etc making out bound network connections except to selected ports, which is where my idea of doing selected port forwarding from the host to the client came in.

curt

Do I detect some misconception of localhost / 127.0.0.1 here? The whole point of 127.0.0.1 is to totally internally reflect any IP traffic sent to it - be it a virtual or a real machine. Therefore anything sent to 127.0.0.1 will never get out of the machine / VM no matter how hard you try, obviously if you listen to 127.0.0.1 then you can only ever listen to messages transmitted by the same machine / VM - not from anything outside (including the host).

Host only networking is something completely different in that it uses a virtual LAN that is contained wholly inside the host machine so that the host and any VMs on that host can talk to each other but using normal IP addresses (usually something like 192.168.x.x).

As Peter says you can change what the machine thinks what localhost is, it's just a logical name after all, so that things going to 'localhost' can escape the machine/VM.

[mbeierl]

Okay, folks: it is possible that the app has been written so that the IP address 127.0.0.1 is used as a literal value in the binary and there is nothing curt504a can do about it. Secondly, wanting to isolate and test an application is valid, so saying chuck the app is not the point here.

Now, on to the problem: 127.0.0.1 is, on most modern operating systems, a specific interface that is bound to a loopback device, and as such can be changed to belong to another device such as vmnet2 or 8. But, this being Windows, I'm not sure that you can do anything with 127.0.0.1. Like this app that is being isolated, I think the 127 network is hard coded into Windows to be local only.

curt504a, that means that only requests generated by the same computer can be serviced by your isolated app. I am not sure anything can be done about that.

As a side note: maybe you might be able to achieve the same result running the offensive application under Wine on a Linux distribution like Ubuntu 7.10? You could then use iptables to mangle the packet header coming in from another interface to appear as though it came from 127.0.0.1.

OR - brain wave here - if there is nothing (such as SSL) preventing a man-in-the-middle attack, you could write a simple proxy program to run on the same VM as the app, and that listens to the external interface on a different port, and then forward the exact data received on to the app, also doing the reverse with the response.