Hey folks -- I'm running CentOS 5 on Parallels Desktop 5. I have the following setup: Mac IP: 10.0.0.42 CentOS VM IP: 10.0.1.5 In Parallels Desktop > Preferences > Network, I'm using Shared Networking and have port forwarding setup as follows: Incoming TCP port 22 ... forward to 10.0.1.5 (CentOS VM) ... to destination port 22 Incoming TCP port 80 ... forward to 10.0.1.5 (CentOS VM) ... to destination port 80 Incoming TCP port 8080 ... forward to 10.0.1.5 (CentOS VM) ... to destination port 8080 Ok -- now I can ssh (port 22) into the virtual machine without any problem using either 10.0.0.42 (the IP of the Mac) or 10.0.1.5 (the direct IP of the virtual machine). Obviously, I'm testing that directly on the Mac as I cannot access the 10.0.1.0 subnet unless I'm on the Mac or one of its virtual machines. Using a PC on my network, I can ssh in using 10.0.0.42. Perfect. Now, I try to connect to port 80. This is where the bug comes in. If I try to connect to 10.0.0.42 from either the Mac itself or a PC on the network, a "protocol not supported" error appears in my browser and in Apache's error log. Apache is trying to use the "ET" protocol. (It should be using the GET protocol, but the G has gone missing.) On my Mac, I try 10.0.1.5 and it works. I think I see what is happening, but for good measure.... So, I stop the web server, write a quick 10-line program that will bind itself to port 80 and read-back what is coming from the socket. Sure enough, if you use a web browser or telnet directly to port 80 of 10.0.1.5, the entirety of your packet is sent. (I type "Foo Bar" and "Foo Bar" is received.) If you use a web browser or telnet directly to port 80 of 10.0.0.42 (which then goes through Parallel's port forwarder), it drops the first byte. (I type "Foo Bar" and "oo Bar" is received.) This explains why, when the web browser is sending the command "GET", all Apache receives is "ET" and says it doesn't support that protocol. I also tried the same experiment on port 8080 with the same results. So it isn't anything special about web browsing or port 80. Now, why does ssh work? Maybe the initial handshaking is a little more fault tolerant, or if the ssh daemon doesn't understand the initial commands, it just defaults. I'd say it's pretty clear this issue is within Parallel's port forwarding engine because everything works perfectly well when you bypass it, and I have opened up a bug report with them, but in the event I'm missing something obvious, I offer this to the group.
Yes, it is an issue in Parallels Desktop 5.0.9220. It is already fixed internally and should work ok in the nearest updated.
Hallo Drew212, I met the same problem recently. I have a host OS with ip cofnig: en0: inet 172.18.4.51 netmask 0xffffff00 broadcast 172.18.4.255 vnic0:inet 10.211.55.2 netmask 0xffffff00 broadcast 10.211.55.255 And the Guest OS is OpenSuse Linux 11.2 with shared network configuration: eth0 Link encap:Ethernet HWaddr 00:1C:42:FE:5B:A3 inet addr:10.211.55.5 Bcast:10.211.55.255 Mask:255.255.255.0 inet6 addr: fe80::21c:42ff:fefe:5ba3/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:199 errors:0 dropped:0 overruns:0 frame:0 TX packets:80 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:60688 (59.2 Kb) TX bytes:19846 (19.3 Kb) Interrupt:10 Base address:0x8200 Now I can access from Guest OS to Host OS, for example I can "ssh" from 10.211.55.5 to both 172.18.4.51 and 10.211.55.2 But I can not access from Host OS to Guest, for example ssh to 10.211.55.5 did not work. But I still can ping to 10.211.55.5 from the Host OS. Can you share your solution with me? Thanks!
HongfuH: My issue was resolved by simply installing version 5.0.9308, released December 18, 2009. Make sure you double-check your firewall settings and port-forwarding settings. --drew
