W2008 => Linux Port forwarding again [Closed]

[G40]

[Edit: Going to stop pursuing this and try using bridging]

Hello and apologies right off the bat. I know this topic comes up 100's of times but I cannot work out what is going wrong.

Any ideas gratefully received. Indeed, I'd be more than happy to offer a bounty if that is acceptable on these fora.

Virtual Box 4.3.10
Host: Colo-server running WS2008R2 x64 with 9 or so I/P addresses. All domains hosted on the machine using IIS7 work precisely as expected.
Guest: Xubuntu 14.04 (slightly lighter weight w/o Unity). Set up using NAT. Accesses the internet just fine. Details of eth0 and route shown below:

The host NIC is assigned a variety of IPV4 addresses. This includes that allocated to the domain in question ending in .43. This address *is* specified in the 'advanced' Windows properties for the NIC.
The VirtualBox manager has a NAT network with DHCP enabled and CIDR of 10.02.0/24. Host port 80 for the .43 address is forwarded to port 80 on the guest. For the sake of completeness both host and DHCP derived IP address are specified in the port forwarding rules dialog.

Any attempt to reach the server running on port 80 on the guest simply times out. This is not a firewall issue as the listening port is visible in netstat. Sadly I'm kind of stuck with the mix of Windows/Linux, at least for another 10 months or so ...

Many thanks.

Jerry.
*
eth0 Link encap:Ethernet HWaddr 08:00:27:b5:f7:09
inet addr:10.0.2.15 Bcast:10.0.2.255 Mask:255.255.255.0
inet6 addr: fe80::a00feb5:f709/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:217456 errors:0 dropped:0 overruns:0 frame:0
TX packets:80816 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:198346170 (198.3 MB) TX bytes:5148357 (5.1 MB)

$ route -n
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.2.2 0.0.0.0 UG 0 0 0 eth0
10.0.2.0 0.0.0.0 255.255.255.0 U 1 0 0 eth0

[Perryg]

Are you using the hosts ip and the guests port number to reach the guest?

[G40]

Hello PerryG

Yes, the host's IP address and port 80 (80 on the host forwards to 80 on the guest).

Many thanks.

[Martin]

Did you try using a different port on the host side? Maybe port 80 is already in use.

[G40]

Hello Martin and thanks.

The only user of port 80 on the guest is my HTTP server. I tried forwarding to 50000 as a sanity check but with the same results I'm afraid. Internally the right HTML page was displayed when browsing to localhost:50000.

If I run the internal HTTP server such that it listens on 10.0.2.15:50000 then I also get the right page displayed in the bowser.

Normally I'd install a low level packet capture package on the host to try and establish what is going wrong. In this case though it might well compromise access to the Co-Lo machine (and it's hosted domains).

netstat -a | grep -i tcp (addresses anonymized)

tcp 0 0 xxxxxxx:domain *:* LISTEN
tcp 0 0 localhost:ipp *:* LISTEN
tcp 0 0 *:50000 *:* LISTEN
tcp 0 1 10.0.2.15:35980 xxxxxxNNN-NNN-251:50000 SYN_SENT
tcp 0 1 10.0.2.15:35981 xxxxxxNNN-NNN-251:50000 SYN_SENT
tcp6 0 0 ip6-localhost:ipp [::]:* LISTEN
tcp6 1 0 ip6-localhost:51470 ip6-localhost:ipp CLOSE_WAIT

[Martin]

I was not talking about the port in the guest.
If some process (IIS?) on the host is already using port 80 the forwarding to the guest won't work.
So you could try to forward host port 8000 to guest port 80 and then try to use host:8000 to reach guest:80

[G40]

+Thanks for that. Interesting point. IIS certainly is running. however I'd have expected the packet for the guest to never have got that far up the host stack(?)

So 2 tests:

1 Stop IIS completely. Verify port 80 is free with netstat. Still no connection on 80 using an external browser
2. Use 8012 on host which forwards to 50000 on guest. This does get through.

So I'm left slightly confused. If the combination of NAT'ing and IIS means port 80 is useless then I'll have to abandon this approach and try bridging

[noteirak]

Thanks for that. Interesting point. IIS certainly is running. however I'd have expected the packet for the guest to never have got that far up the host stack(?)

Why not? in NAT mode, Virtualbox is like a regular process, it has to bind on an IP and a port. This binding process is on a first come first served basis.
If that IP & port is already bound onto, then Virtualbox won't get it.

1 Stop IIS completely. Verify port 80 is free with netstat. Still no connection on 80 using an external browser

Did you remove the port forwarding and then added it again, or restarted the guest? If you don't, then the binding will not happen automatically.
Virtualbox will try to bind at the different times :
- At VM startup, for what ports were already configured
- At VM runtime, for any new port you configure

I'll have to abandon this approach and try bridging

Bridging is the RIGHT way of doing this. Or to phrase this better: NAT is the WRONG way of doing this.
NAT is designed for normal usage when connections come out of the VM, and not go in. It is not optimized for that, and you'll run into this kind of problems.
Bridged on the other hand, is making the VM like another regular entity on the network, with its own IP, so you won't run into reservation issues.

For reference, have a look in the different networking topics, you will see that 99% of the time, it's a user or configuration issue - and I do answer on all of them.
Bugs or issues in networking are extremely rare in Virtualbox (except NAT Networking which is experimental), so always consider the human error first.

[G40]

Thanks for the comments and yes I agree that bridging is a much better solution than NAT/port forwarding.

However it is rarely as simple as it sounds. Networking, especially on a co-lo machine, is difficult to debug. See my next issue here: viewtopic.php?f=6&t=61833

[noteirak]

it is rarely as simple as it sounds. Networking, especially on a co-lo machine, is difficult to debug.

Networking is not difficult, it's not just forgiving. You must be precice and know what you're doing, there is no room for guess or approximation. It works, or it doesn't.
And it won't work until you get it right exactly

I'll have a look at your next issue.