You said "but I cannot activate Bridging/NAT and directly access the network from the VM". What do you mean by this?
I believe when you create/edit your VM settings (i.e. before actually "play" and getting INTO the VM to use it), that's where you specify your network setup. And NAT would be the default arrangement (as it was for me) which doesn't provide access to the real LAN objects (e.g. 192.168.1.x) once running inside the VM. Only the drives of the host machine are potentially available to the VM, so that you can perhaps "map network drives" to give drive letters to Windows Explorer while running in the VM to real local drive letters for the host.
Otherwise, if you instead check "Bridged, connected directly to the physical network" in the Settings before entering the VM guest, well now you DO have genuine access to the whole LAN and all of its 192.168.1.x objects... same as the host has. That's how I have my own Win7 VM guest running on a Win10 host, only after discovering this networking Bridged/NAT choice. So I now have full "Network" access in Windows to all LAN machines and devices with their own IP addresses, as well as all shared network PC's and other network folders and objects that appear in Windows Explorer NETWORK.
And yet you say "I cannot activate Bridging/NAT". What do you mean? Where and when are you trying to do this, and what is the result?
Hi, when I wrote "I cannot activate Bridging/NAT and directly access the network from the VM" I meant just that. The VM must not have direct access to the network, it has to be isolated from the network.
You can use a "host-only" networking as an option, then. That way the VM can still access network resources on the host (and vice-versa), but not reach the outside network.
Hi, the resource I'm trying to reach is on the external network! I cannot see it from the internal host-VM network.
Well, now I'm really confused. First you state that the VM CANNOT have a connection to the external network. Then you state that the resource you are trying to access IS on the external network. So, which is the case? Are you trying to keep the VM isolated (and therefore you will NEVER be able to access the external resource from it), or are you trying to access a networked shared resource which is on your host from the VM? Or something else entirely??
Well, then I too am confused as to exactly what you're trying to "see" from the VM. And we need to be unambiguous as to what you really mean when you use terms like "access to the network".
For the sake of discussion (and you can tell me if your notions are different) I think of "the network" as my LAN, supported by my router (with say a gateway IP address of 192.168.0.1), with any number of PC's and ethernet-enabled devices all connected to the router through either ethernet cables, wireless, or switches, and with each device assigned its own IP address say of the form 192.168.0.2, 192.168.0.3, etc.
I think of local drives on the host as non-network resources, since they're not involved with the router.
And I think of internet-located locations (i.e. on "the other side" of the LAN and router) as truly external.
I don't know why you have some requirement that "the VM MUST NOT HAVE ACCESS to the network", and again exactly how you define "the network".
In my own experience, my initial Win7 VM creation specified NAT for networking, because I was unaware of what this was or what it implied. It did, however, allow me to see all of the local drives on the host as "network drives" to the Win7 VM. So I was able to use Windows Explorer to set drive letters for the local host drives as "mapped network drives" to the Win7 VM. But I was unable to see any other PC's or ethernet-enabled devices with their own IP addresses on my LAN from the Win7 VM, which was contrary to my own requirements which potentially made use of those LAN-based devices through programs running in the Win7 VM (same as they'd run when on a real physical Win7 PC).
So I changed "NAT" to "bridged" for networking. And now I was not only able to "map network drives" to give drive letters in the Win7 VM to the host's local partitions, but I was now also presented in the WIn7 VM with the complete set of 192.168.0.x PC's and ethernet-enabled devices on my LAN... exactly the same as the host itself saw. This then allowed me to make full use within Win7 VM to whatever functionality is facilitated by that connectivity from the Win7 VM to all of these LAN-based devices. Plus, I could obviously also see the outside Internet world, through the modem connected to the router... just like the host and all other LAN-based devices could.
This now is EXACTLY what I had hoped for, with the Win7 VM running as its own machine on the LAN exactly as the real physical Win7 machine it replaced would have also appeared on the LAN. No more or less functionality than any true physical machine or device on the LAN would be entitled to.
So, to clear up the confusion... exactly how would you describe your situation and its needs? Why mustn't the VM have direct access to the network, whatever you are considering to be "the network"? What could be wrong by having all the other 192.168.0.x devices at least "visible" to the VM via "bridged" networking?
Hi, probably I'm not enough proficient in written english, I will try to explain better.
PC1 runs Windows 10 Pro. It is connected to a physical LAN. Several hosts are connected to the physical LAN, including a server that shares some folders, and a router that connects the entire network to the Internet.
Fron PC1 I can access several of the shared folders on the File server, by entering the appropriate username and password.
VMWare is executed on PC1. The OS running in the virtual machine (Windows 7 Pro) must not be able to have access neither to any PCs on the physical local network, nor to the Internet. It should be only able to access a specific folder shared by the file server.
To achieve this, I've tried to map the above mentioned shared folder to a network drive on PC1, and then share that drive with the VM by using the shared folder feature of VMWare. But it doesn't work, because apparently VMWare uses a built-in Windows user account (SYSTEM, probably) to access the shared folders. It doesn't use the current user, that has access to the mapped network drive.
I hope that now it's clearer.