UDP NAT port forwarding broken

[Xavier Pitz]

---

Windows PC IP : 192.168.30.2 (condor client connecting UDP 192.168.30.3:57278)

---

Linux host IP : 192.168.30.3 (NAT 192.168.30.3:57278 --> 10.0.2.15:57278 (extradata set))

Windows guest IP : 10.0.2.15 (condor server listening on UDP port 57278)

---

The guest app properly listen on 10.0.2.15:57278 (TCPview confirms it) but the Windows PC client is never able to establish a proper communications with it.

Following extradata were configured for the VM :

Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/CD57278/Protocol, Value: UDP

Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/CD57278/GuestPort, Value: 57278

Key: VBoxInternal/Devices/pcnet/0/LUN#0/Config/CD57278/HostPort, Value: 57278

I then also forwarded UDP ports 57279 & 57280 from the host to the guest, and was looking to test with another UDP client/server software. I tried scorched 3D. I was able to see in the scorched 3D server, that the incoming connections from the client appeared as coming from the guest virtual default gateway (10.0.2.2) and not from the windows client IP (192.168.30.2). This is why I think UDP NAT is broken in VirtualBox 1.5.2. NAT Translation based on virtual default gateway IP instead of the real origin IP maybe. I think that no NATed UDP applications are yet able to communicate with external machines (except the host itself maybe).

[Xavier Pitz]

Hello,

I performed additional test with WireShark to have a look at the IP packets sent/received by both client/server ethernet (virtual)interfaces. (client=windows PC / server=windows guest running inside a ubuntu 7.10 host)

Those captures confirm what I previously thought. Please have a look with WireShark at boths pcap(s) file (packet capture). Or have a look at both png(s) if you don't have WireShark (​http://www.wireshark.org/)

Regards,

Xavier Pitz

[Xavier Pitz]

PS :

You can clearly see on the serverside that the packets seems to be sent (1st packet) by a client (source) at IP@ 10.0.2.2. [The real client IP was 192.168.30.2 but was mistranslated by the virtualization software]
This is why the server program send an answer (2nd packet) to this client (this time it ist the destination) with destination IP@ 10.0.2.2.
The answer is never received by the client because IP@ 10.0.2.2 was not the client.

---

clientside :
The client retries 4 additional times before resigning.
This is why you have 5 packet sent from the clientside.

---

serverside :
You have 5 packets received on the serverside (but with a mistranslated source IP)
Then you have also 5 packets sent from the serverside but to a non-existent client.

[Xavier Pitz]

PS2 :

I think that the the real source originating IP / port from an incoming UDP packet should only been passed through and not translated at all by the virtualization software.

[Klaus Espenlaub]

I can confirm that UDP forwarding was completely broken. Fixed those inappropriate port translations in our internal tree (change will appear in the OSE SVN tree in the next days).

Actually there is exactly one case where translating the IP address is necessary: if the UDP packet comes from the host and it sent to 127.0.0.1. But this is an unusual boundary case which shouldn't matter much in real life.

Just as a side note: does anyone know of a good NAT engine which uses the socket interface on the host and provides a packet interface on the guest side? Please don't suggest slirp, because that's what I just fixed and the more I look into it the more I dislike it.