I have 3 systems -
- Windows 10 system with firewall disabled
- CentOs 8 system with firewall disabled (firewall status is inactive)
- Windows 10 VM on the CentOs 8 machine described above with firewall disabled
For some reason, I am unable to connect these 3 on a single network. All 3 machines have been given static IPs, as -
Static IP -
192.168.1.10, 192.168.1.125, 192.168.1.25Subnet mask -
255.255.255.0Default gateway -
192.168.1.1The Linux system and Windows 10 VM hosted on top of it connect fine (via a host adapter for VirtualBox, having adapter IPv4 value as 192.168.1.11), and can even ssh into it.
However, the Windows 10 standalone system is unable to locate,pingor even ssh into any of these systems. With dynamic IP provided by my provider, they are able to connect well enough, but when I connect the 2 systems (Windows 10 and Linux systems) via an ethernet cable in a standalone, sort of p2p network, they just do not find each other.
IPv6 is disabled in each of the network configurations. The only thing I can think of is that the machines do not specify the same workgroup, since my Windows 10 system is signed on to a domain, and my Linux system (with Windows 10 VM) is not, but in the scenario described above, there is no domain activity, since the machines are connected via LAN cable and are not on any other network.
UPDATE -
ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever
2: enp1s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 00:04:5f:9e:94:43 brd ff:ff:ff:ff:ff:ff inet 192.168.1.10/24 brd 192.168.1.255 scope global noprefixroute enp1s0 valid_lft forever preferred_lft forever inet6 fe80::204:5fff:fe9e:9443/64 scope link valid_lft forever preferred_lft forever
3: enp0s31f6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc fq_codel state DOWN group default qlen 1000 link/ether 00:04:5f:9e:94:42 brd ff:ff:ff:ff:ff:ff
4: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000 link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0 valid_lft forever preferred_lft forever
5: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc fq_codel master virbr0 state DOWN group default qlen 1000 link/ether 52:54:00:31:3c:a5 brd ff:ff:ff:ff:ff:ff
6: br-c91ce55ad4d6: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:e6:4e:bd:04 brd ff:ff:ff:ff:ff:ff inet 172.18.0.1/16 brd 172.18.255.255 scope global br-c91ce55ad4d6 valid_lft forever preferred_lft forever
7: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default link/ether 02:42:ca:60:cc:f5 brd ff:ff:ff:ff:ff:ff inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0 valid_lft forever preferred_lft forever
8: vboxnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000 link/ether 0a:00:27:00:00:00 brd ff:ff:ff:ff:ff:ff inet 192.168.1.11/24 brd 192.168.1.255 scope global vboxnet0 valid_lft forever preferred_lft forever inet6 fe80::800:27ff:fe00:0/64 scope link valid_lft forever preferred_lft forever ip route
default via 192.168.1.1 dev enp1s0 proto static metric 100 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.18.0.0/16 dev br-c91ce55ad4d6 proto kernel scope link src 172.18.0.1 linkdown
192.168.1.0/24 dev vboxnet0 proto kernel scope link src 192.168.1.11
192.168.1.0/24 dev enp1s0 proto kernel scope link src 192.168.1.10 metric 100 linkdown
192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1 linkdown1 Answer
The Linux system and Windows 10 VM hosted on top of it connect fine (via a host adapter for VirtualBox, having adapter IPv4 value as 192.168.1.11), and can even ssh into it.
Your problem is here. You have two physically separate networks which just happen to be numbered 192.168.1.x on both sides. However, they're still separate networks; packets do not automagically flow from one interface on the host Linux system to another.
Your VMs might still have Internet access because you or your VM software has probably configured the Linux host to act as a router/gateway, complete with NAT. (NAT is duct tape for networks.)
However, because the network numbers are the same on both sides, your VMs think that every 192.168.1.x address is local (that's what the subnet mask tells them!), so they do not use a gateway to reach them. As a result the two sides cannot reach each other in normal configuration.
The Linux host also doesn't cope well with two interfaces being on the same subnet. You can see that ip route has two entries for the same destination; only one of them is used. The OS doesn't keep track of which individual hosts are on which side.
You have four options:
Continue using routing, but change the VirtualBox "Host adapter" (vboxnet0) IP address to a different network, e.g. 192.168.2.x will do the job.
Merge both networks using Linux bridging: Create a bridge on the host (ip link add br0 type bridge), then put both your real Ethernet and the VirtualBox virtual interface into the bridge (ip link set eth0 master br0). Remove IP addresses from both interfaces, and configure 192.168.1.11/24 on br0 (the bridge) instead.
Merge both networks using VirtualBox bridging: Change the VM configuration to use "Bridged networking" and select the physical Ethernet interface. This will only work as long as your Ethernet is configured.
Create two interfaces in the VM: one for host networking like now, one for bridged networking with your physical Ethernet.
The only thing I can think of is that the machines do not specify the same workgroup,
Absolutely irrelevant. The only thing a "workgroup" does is limit which machines show up in the List Of Network Computers, practically. (The NetBIOS "computer browsing" mechanism was designed in 1980s and workgroups were used to limit how much data each LAN computer had to hold.) It does not affect communication at IP or TCP level, and for that matter it doesn't even affect direct Windows SMB file sharing connections.
9
