For those users on a corporate network that need an active directory and need to keep it hidden from the corporate network, setting your VM network to internal will do this as will private.
The added advantage of setting things to internal means that the Host machine can access the internal network also, but none of the AD traffic or broadcasts from the internal machine get out onto the wider corporate network. There may be one or two exceptions. If you have a shared folder on the host machine so you can copy files to the internal machines it will authenticate against the corporate network (unless you granted everyone rights, you did ? really?). That authentication is relayed from the host to the corp network. One of millions of auth requests on your network, so if you’re trying to hide there is some safety in numbers, unless you’re on the MOD network or similar, they will send the marines in to get you.
The other advantage of Internal network over private is that you can run a proxy server on the host, this proxy server can be something as simple as fiddler or tcp-trace, again standard dev tools, nothing to see here. By running fiddler with allow remote computers to connect, any machine with it’s WinINET proxy settings configured to point at your host machines:8080 port (or other if you set it like that) to route TCP(web) traffic via your machine it will determine where that traffics needs to go. If your traffic is from the VM’s then it will route that traffic to the next upstream proxy/gateway to the internet (external corp machines) and like wise if one of your dev mates points at your proxy server then they can browse your internal VM webs. In order to get from the host to the internals you will need to make entries in your hosts file, fiddler has a menu option to allow you to edit it quickly.
With all this in place and my utilisation of a custom pac script and fiddlers hosts file, other devs in my team automatically route to my fiddler when they type in the address http://simonssharepoint.simon.devlan.local because the pac file directs them to my fiddler, fiddler knows to direct to the internal machine as it has a host entry for it, the AAM handles the name, all without going anywhere near the corporate DNS server, I can of course add that url to my internal VM’s DNS entries. Also my VM’s can access the internet as the DNS server forwards to the host dns server, forwards to the corp dns server (with 184.108.40.206 as a backup) and then all IP traffic routed through fiddler on the host machine to the internet. The only thing I cannot do is access file shares from the outside world to the inner VM’s and vice versa. I have to copy stuff onto the host and off to the VM or external when doing file copies, opening that protocol exposes all sorts of things and is a big “LOOK AT ME IM IN YOUR INTERNETZ”.
One of the config problems we hit was the internal network was registering itself into DNS, this caused issues when I wanted to MSTSC onto my host machine and it returned a 192.168.1 address, which of course the corp network machine could not locate and its a big HELLO i’m on your corp network, doing weird stuff. So to make sure your internal machine does not do that you need to untick the option that does that.
To get to this advanced TCP/IP settings, on your virtual network card select the properties, select IPv4 properties->Advanced->DNS tab. Untick that register in DNS option at the bottom.
The other belts and braces option you need to change, once unregistered this shouldn’t be necessary but, we should set the priority of the network device to be the physical, it may not be.
In this next dialog you can set the order in the top box. In the example shown here, the “Physical LAN card” is the actual NIC, this is used by HyperV as a switch so this is not the one we want. The “LAN” option is the virtual network attached to the Physical (corporate) side of the networks and this should be at the top of the priority list. The others shown “Local Area Connection” is my unused secondary physical NIC that can be ignored. The last being the DevLan.Local which is the virtual network on the Internal side.
If you have managed to register the 192… range address in DNS, and you will know this because no-one can connect to your machine on your main network or they ping you and the 192 address is unreachable, well you can fix this.
After you corrected all the DNS and IP things as discussed above
In a CMD prompt window type
IF you are having trouble from another computer as it hasnt refreshed its DNS tables then you can on that machine
This should clear the machine and force a refresh of your newly registered correct IP addresses.
There is one more thing I’m investigating regarding VPN access but until I prove it I’ll leave it out but I will add to this later as this might effect the IP address range you choose*.
*Still investigating this, but essentially, most peoples home network is on an IP address range of 192.168.1.n so as your local machine has been configured to have its internal network also configured in this range, Im told the reason I might not have been able to connect over VPN is the the return address (despite all the NAT things going on) is in the 192.168.1.* range and therefore the routing table of the main company “host” machine says I know how to route there and sends all traffic that should be going to your home machine over the VPN to the internal network. This all sounds dubious to me and I most likely had problems because of the IP address in DNS and IP is intelligent enough to route the VPN traffic back over the VPN and the VPN will know to send it back to the client. I have some testing to do now my DNS is fixes using a 192.168.1.* and a 192.168.2.* range set on my home machine and see if both can VPN in.