Wi-Fi can be run as an access point or a router, if you’re running a router then you’ll need to account for any NAT and other routers in the configuration. Routers are most commonly configured with separate IP subnets, and trying to use a router within the same subnet isn’t something I’d usually recommend.
Fire Sharing over the open Internet isn’t something I’d recommend in general, for reasons of security. It’s also possible that some ISPs will block thst traffic. The firewall and all intervening devices must be enabled and configured to support that access; port forwarding or firewall rules will be required, and that’s device- and network-specific. (I’d usually recommend using a VPN into the local network such as into a VON server in the gateway-router-firewall box. This to protect the traffic, and to reduce the numbers of IP ports that the remote gremlins can poke at and can fill the logs of, and maybe also find any weak passwords of.)
Guests in a virtual machine add another layer of complexity to the configuration, as you)re inherently working with virtualized hardware, or you’re subsetting your hardware configuration and mapping physical hardware through into the guest. There’s not a lot of networking hardware in a MacBook Pro, so you’re left to map wired and Wi-Fi, or add additional connections cia Thunderbolt or USB. Many folks use virtual hardware, and share access. Some VM packages add additional IP addresses to the host hardware network controller and make a path to that address available to the guest, others set up a virtual private NAT’d network within the VM package and the user is left to get that NAT’d network out of the VM and through the host and out to the local network, and double-NAT adds its own complexity here. All of which means you really need to understand IP networking and subnets and IP routing to get anything in or out of the guest, through the host operating system, and out to the local network, and maybe then port-forwarded and accessible further from there. Some VM packages are better at this virtual networking than others.
ISP routers are intended to be easy for the ISP to support and cheap to buy in large quantities, and cheap to automate, and simple to reset back to ISP defaults. Convenience and flexibility for the end-user tends to be further down the list of the usual ISP selection criteria. If you’re intending to do more complex configurations, switching the ISP box into bridged mode or replacing it with a gateway-firewall-router that better meets your needs may be a good choice.
The point I’m trying to make here is that networking configurations can be complex, and VM guest networking can be some of the more complex to configure. Further, a whole lot more detail around the networking hardware present, and the virtual machine (if running Windows as a guest) and the ISP router box (for external links and in-bound remote access), in use in this case. Using Boot Camp and eliminating the virtual machine is less complex, as you’re working with a Windows box connected to a network. Which is pretty much the default configuration of a Windows box these days.
I’d start with a less-complex network configuration, get that working, and then add the next piece and reconfigure for and get that working. Boot Camp with Windows or macOS file sharing, then add whatever additional pieces are necessary. I’d use Acess Point (AP, bridged) mode where you can, as that can simplify the IP network configuration.). You may find that the ISP blocks in-bound screen sharing or in-bound file-sharing protocols, too. You will find that the network firewall will need to be reconfigured to allow remote in-bound access. And you will get probed and quite possibly then attacked via any open IP ports. Usually within minutes. Plan for those attacks to happen, too.
