Unexpected behavior in IP address assignment in NAT and NAT Network networking modes

[lfs]

I have observed an unexpected behavior in the assignment of IP addresses in NAT and NAT Network networking modes. I am using VirtualBox 6.0.10, the host OS is Windows and the guest OS is Ubuntu; I have observed the same when the host OS is Ubuntu; also the same with the previous VirtualBox 6.0.8 (I didn’t try other versions).

When using the NAT mode, being the network prefix 10.0.2.0/24, I see the following:

• 10.0.2.1 is not assigned (no ping response)
• 10.0.2.2 is assigned to the internal interface of the NAT router (from the routing table; ping ok); the corresponding MAC address is 52:54:00:12:35:02 (from the ARP table or from the capture of ping packets)
• 10.0.2.3 is assigned (ping ok); the corresponding MAC address is 52:54:00:12:35:03, different than internal router interface’s MAC address (from the ARP table or from the capture of ping packets).
• 10.0.2.4 is assigned (ping ok); the corresponding MAC address 52:54:00:12:35:04, different than the two previous MAC addresses (from the ARP table or from the capture of ping packets).
• 10.0.2.5 is not assigned, etc.
• 10.0.2.15 is assigned to the VM interface.
• DHCP server is bound to 10.0.2.2, the internal router interface (from the capture of DHCP packets or other)

The expected behaviour would be that just one IP address was assigned, and to the internal router interface. Why 10.0.2.3 and 10.0.2.4 are assigned? To which Ethernet interfaces correspond?

When using the NAT Network mode, being the network prefix 10.0.2.0/24 and the DHCP service enabled, I see the following:

• 10.0.2.1 is assigned to the internal interface of the NAT router (from the routing table; ping ok); the corresponding MAC address is 52:54:00:12:35:00 (from the ARP table or from the capture of ping packets)
• 10.0.2.2 is assigned (ping ok); the corresponding MAC address is 52:54:00:12:35:00, that is, the same as the internal router interface (from the ARP table or from the capture of ping packets); therefore 10.0.2.1 and 10.0.2.2 are both assigned to the internal router interface.
• 10.0.2.3 is assigned (ping ok); the corresponding MAC address is 08:00:27:5f:59:1f, different than internal router interface’s MAC address (from the ARP table or from the capture of ping packets).
• 10.0.2.4 is not assigned, etc.
• 10.0.2.15 is assigned to the VM interface.
• DHCP server is bound to 10.0.2.3, which is not the internal router interface (from the capture of DHCP packets or other)

The expected behaviour would be that just one IP address was assigned, and to the internal router interface, and that the DHCP server was bound to this IP address. Why 10.0.2.1 and 10.0.2.2 are both assigned to the internal router interface? Why 10.0.2.3 is assigned? To which Ethernet interface corresponds? Why the DHCP server is not “running” on the internal router interface?

Thanks

[scottgus1]

Trying NAT, guest IP address 10.0.2.15, I get pings back from:
10.0.2.2 <- gateway, DHCP
10.0.2.3 <- unknown
10.0.2.4 <- unknown
10.0.2.15 <- guest self-ping

Trying NAT network, guest IP address 10.0.15.6, I get pings back from:
10.0.15.1 <- gateway
10.0.15.2 <- unknown
10.0.15.3 <- DHCP
10.0.15.6 <- guest self-ping

I used ipconfig /all to get what ip addresses were identifiable. The results seem to be the same pattern of IP addresses you're getting.

My physical LAN router has only its own gateway and DHCP server on 192.168.0.1.

Why the extra addresses? What the unknowns are? Have no idea. Does this arrangement cause any problems in your guests?

FWIW, NAT network allows multiple guests to attach, but NAT only allows one network card to attach. NAT network is like a typical router with multiple LAN ports. NAT is a router with only one LAN port.

[lfs]

Thanks for the answer and for confirming this unexpected behavior in IP address assignment.

It does not cause any problem in my guests, I mean, they get a right IP address from the DHCP server and they have connectivity to the external network and (in the case of NAT Network) to other VMs. My point was to notify that this behavior is not correct since it does not correspond to the "model" of NAT and NAT Network mode, that is, a NAT router with one Ethernet interface in the internal network, a DHCP server in this interface and just one internal IP address assigned to it. Something must be wrong in the current (and in the previous 6.08) implementation. I am not sure but I think this wrong behavior didn't happen in older versions of VirtualBox.

[fth0]

I also cannot answer the question why there are different IPv4 addresses used for the multiple roles of a single DHCP server/router instance. What I can say is that one of the unknowns is the TFTP server address (delivered by the DHCP server), where the DHCP client can download the boot image in case of a PXE boot. You can see this when capturing the DHCP negotiation with Wireshark or tcpdump.

[corentin266]

Hello!

I have been using a Debian (9~12) Guest on Windows Host for quite some time with a NAT interface and port forwarding (SSH & web ports). The guest's IP was 10.0.2.15, the gateway was 10.0.2.2, and everything was fine. The guest was able to communicate with the host on 10.0.2.2 (for PHP Xdebug on port 9003).

Recently, I installed the same configuration but with a Red Hat Enterprise 9.3. Everything looked good at first glance (the guest had internet connectivity), and connections from the host (e.g., Apache logs) showed as 10.0.2.2. However, when I tried to set up my Xdebug, the guest was unable to "directly" connect to 10.0.2.2 at all. Ping was not possible either.

I was on the verge of a breakdown until I randomly tried to ping 10.0.2.3, and it actually worked. What gives?

My guest can contact the host via 10.0.2.3 and 10.0.2.4, but not 10.0.2.2

[fth0]

Sounds like a known issue that was fixed in VirtualBox 7.0.12. Current VirtualBox version is 7.0.14.

[corentin266]

Unfortunately i have 7.0.14
But at least i found a solution by using 10.0.2.3

I can't understand why i have no problem with Debian but this weird behavior with Red Hat.