Opened 10 years ago
Closed 9 years ago
#13753 closed defect (invalid)
No gateway access for Linux Guest on NatNetwork
| Reported by: | NetSecNinja | Owned by: | |
|---|---|---|---|
| Component: | network/NAT | Version: | VirtualBox 4.3.20 |
| Keywords: | natnetwork | Cc: | |
| Guest type: | Linux | Host type: | other |
Description
VirtualBox version: 4.3.20 r96997 Host OS: Windows 8.1 Guest OSes: Windows 7, Windows XP, Ubuntu, Kali
Synopsis: Linux guest OSes get invalid MAC address for NatNetwork gateway, resulting in no outside connectivity from inside Nat Network. Connectivity to other guest OSes inside Nat Network not affected. Windows Guest OSes are unaffected. It appears there are two hosts defined as the default gateway in a NatNetwork environment, which causes two ARP responses when determining who has the DG IP address.
Setup:
VBoxManage.exe natnetwork add --netname Lab --network 10.1.0.0/24 --enable --dhcp on
VBoxManage.exe dhcpserver add --netname Lab --ip 10.1.0.1 --netmask 255.255.255.0 --lowerip 10.1.0.2 --upperip 10.1.0.25 --enable
Confirmation: Boot into a Windows Guest OS and a Linux Guest OS, both connected to same Lab NatNetwork. Run the following commands on the Windows Guest. Note the default gateway (DG) IP, correct route, MAC address for DG, and successful ping of DG:
C:\Documents and Settings\Lab>ipconfig /all
Windows IP Configuration
Host Name . . . . . . . . . . . . : xp
Primary Dns Suffix . . . . . . . :
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : AMD PCNET Family PCI Ethernet Adapte
r
Physical Address. . . . . . . . . : 08-00-27-B4-60-7E
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 10.1.0.4
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 10.1.0.1
DHCP Server . . . . . . . . . . . : 10.1.0.1
DNS Servers . . . . . . . . . . . : 75.75.75.75
75.75.76.76
Lease Obtained. . . . . . . . . . : Sunday, January 11, 2015 6:13:55 AM
Lease Expires . . . . . . . . . . : Sunday, January 11, 2015 6:33:55 AM
C:\Documents and Settings\Lab>route print
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...08 00 27 b4 60 7e ...... AMD PCNET Family PCI Ethernet Adapter - Packet S
cheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 10.1.0.1 10.1.0.4 20
10.1.0.0 255.255.255.0 10.1.0.4 10.1.0.4 20
10.1.0.4 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.1.0.4 10.1.0.4 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.1.0.4 10.1.0.4 20
255.255.255.255 255.255.255.255 10.1.0.4 10.1.0.4 1
Default Gateway: 10.1.0.1
===========================================================================
Persistent Routes:
None
C:\Documents and Settings\Lab>arp -a
Interface: 10.1.0.4 --- 0x2
Internet Address Physical Address Type
10.1.0.1 52-54-00-12-35-00 dynamic
C:\Documents and Settings\Lab>ping 10.1.0.1
Pinging 10.1.0.1 with 32 bytes of data:
Reply from 10.1.0.1: bytes=32 time=33ms TTL=255
Reply from 10.1.0.1: bytes=32 time<1ms TTL=255
Reply from 10.1.0.1: bytes=32 time<1ms TTL=255
Reply from 10.1.0.1: bytes=32 time<1ms TTL=255
Ping statistics for 10.1.0.1:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 0ms, Maximum = 33ms, Average = 8ms
C:\Documents and Settings\Lab>
Run the following commands on Linux OS. Note the correct DG, but incorrect MAC address which results in failed ping of DG.
root@kali:~# ifconfig
eth0 Link encap:Ethernet HWaddr 08:00:27:85:7a:38
inet addr:10.1.0.2 Bcast:10.1.0.255 Mask:255.255.255.0
inet6 addr: fe80::a00:27ff:fe85:7a38/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:21908 errors:31 dropped:0 overruns:0 frame:0
TX packets:6982 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:27058452 (25.8 MiB) TX bytes:691758 (675.5 KiB)
Interrupt:19 Base address:0xd020
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:86870 errors:0 dropped:0 overruns:0 frame:0
TX packets:86870 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:15344386 (14.6 MiB) TX bytes:15344386 (14.6 MiB)
root@kali:~# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 10.1.0.1 0.0.0.0 UG 0 0 0 eth0
10.1.0.0 * 255.255.255.0 U 0 0 0 eth0
root@kali:~# arp
Address HWtype HWaddress Flags Mask Iface
10.1.0.1 ether 08:00:27:6f:0a:ff C eth0
root@kali:~# ping -c 4 10.1.0.1
PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data.
--- 10.1.0.1 ping statistics ---
4 packets transmitted, 0 received, 100% packet loss, time 2999ms
root@kali:~#
Troubleshooting: I have tried this on Kali and Ubuntu OSes with the same result. I have cleared out the erroneous MAC (arp -d 10.1.0.1) and attempted to re-detect the correct one by pinging the DG again. Both Linux OSes show the same MAC for the DG. Packet capture via tcpdump shows that the erroneous MAC is being advertised back from 10.1.0.1, followed by the correct MAC. Since there is already an ARP entry for the DG, this second packet is discarded as a duplicate IP:
root@kali:~# tcpdump -ni eth0 arp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 06:35:58.156234 ARP, Request who-has 10.1.0.1 tell 10.1.0.2, length 28 06:35:58.156608 ARP, Reply 10.1.0.1 is-at 08:00:27:6f:0a:ff, length 46 06:35:58.156693 ARP, Reply 10.1.0.1 is-at 52:54:00:12:35:00, length 46
Workaround: Delete detected DG MAC and statically set correct one discovered from Windows Guest (must be run after each boot):
root@kali:~# arp -d 10.1.0.1 root@kali:~# arp -i eth0 -s 10.1.0.1 52:54:00:12:35:00 root@kali:~# ping -c 4 10.1.0.1 PING 10.1.0.1 (10.1.0.1) 56(84) bytes of data. 64 bytes from 10.1.0.1: icmp_req=1 ttl=255 time=0.330 ms 64 bytes from 10.1.0.1: icmp_req=2 ttl=255 time=0.297 ms 64 bytes from 10.1.0.1: icmp_req=3 ttl=255 time=0.386 ms 64 bytes from 10.1.0.1: icmp_req=4 ttl=255 time=0.488 ms --- 10.1.0.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 3003ms rtt min/avg/max/mdev = 0.297/0.375/0.488/0.073 ms
Change History (5)
follow-up: 2 comment:1 by , 10 years ago
comment:2 by , 10 years ago
Replying to vushakov:
For a quick sanity check - do you have any guests with MAC
08:00:27:6f:0a:ff?
Thanks for the sanity check Vushakov, I can use the extra brain-power on this problem. I did check each of my VMs, and none of them have that MAC. I even dug through the .vbox file for each VM making sure it wasn't a previously used MAC and I didn't find it.
follow-up: 4 comment:3 by , 10 years ago
Ah, you specify 10.1.0.1 as the IP address to the DHCP server, but .1 and .2 addresses are used by the proxy itself, hence the conflict.
The .3 address will be used for DHCP by default when you create natnetwork with DHCP enabled but don't do dhcpserver add.
comment:4 by , 10 years ago
Replying to vushakov:
Ah, you specify
10.1.0.1as the IP address to the DHCP server, but.1and.2addresses are used by the proxy itself, hence the conflict.The
.3address will be used for DHCP by default when you create natnetwork with DHCP enabled but don't dodhcpserver add.
That did it! I removed my self-defined DHCP server, and just for good measure, deleted then re-created my NATNetwork. Thanks for your help!
comment:5 by , 9 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
For a quick sanity check - do you have any guests with MAC
08:00:27:6f:0a:ff?