If you had one Server behind the router which would host all pages under serveral hostnames Name Based Virtual Hosting would be working for you the way you suggest.
Since you are talking about different hosts, and since hosts communicate via TCP/IP and not via HTTP this won't work. In fact the Router or the Hosts per se could not care less about the HTTP/1.1 Hostname provided
You are left with the possibility to setup a reverseproxy which will take all requests coming in via the Red Zone and then distribute the requests to the application Servers in the Green Zone.
You might do NameBased Vhosts on the Reverseproxy if you need to.
DNS settings are incorrect. DNS IP's point to DNS servers, the terminology of "DNS gateways" is incorrect and misleading as DNS servers only respond to queries, they don't do any packet routing.
On Windows Server:
-In IPv4 TCP/IP properties change primary DNS server to 192.168.0.8 (no secondary DNS)
-Do an "ipconfig /registerDNS", reboot.
In DHCP server scope (currently this is the router):
-Change primary DNS server to be 192.168.0.8 (Windows Server IP)
-Do not use a secondary DNS server unless there is a 2nd AD DNS server on the LAN.
Note that w/ a Windows server in place then network browsing works better if DHCP is done on server & DDNS is enabled. See:
http://technet.microsoft.com/en-us/library/cc771255.aspx
http://en.wikipedia.org/wiki/Dynamic_DNS#Function
Workstations:
Reboot or "ipconfig /renew" after above changes are completed.
Yes, if the Windows DNS server goes down then the internet is also down. If that's the case then there will be larger issues and the DHCP scope on the router can be enabled at that time.
Because AD depends on DNS internal workstations should only use internal AD DNS servers. Having an external 2ndary DNS will cause unpredictable browsing, logon and network performance issues in an AD domain.
Using a .com like BVOffice.com for an AD name is often problematic and not recommended IMO. Currently there are no public DNS records but if this is not your domain name then I would either buy it, but I would still change the internal AD name to bvoffice.local. Using .com for an AD name can be managed (mostly...) but requires a good understanding of DNS and TCP/IP.
Best Answer
Based on the limited information in the question it is not possible to say for sure why connectivity using a hostname works but connecting to the very same server using an IP address does not work.
However I guess the most likely explanation is the client is depending on DNS64+NAT64 in order to connect to the server. Since IPv4 addresses ran out, deployments of various kinds of CGN solutions have become more common. One of them is DNS64+NAT64, and those has the limitation that clients cannot connect to IPv4 servers by IP address.
What will happen when such a client connects to an IPv4-only server is this:
server.example.comserver.example.comserver.example.com192.0.2.1192.0.2.1into64:ff9b::192.0.2.164:ff9b::192.0.2.164:ff9b::192.0.2.1to192.0.2.1If the client is OpenSSH, you can use
ssh -von the client side to see which IP address it is connecting to. If the server is IPv4 only, and the client connects to an IPv6 address when given the hostname, you will know that the client is depending on DNS64+NAT64.Possible mitigations if you cannot connect to IP address due to NAT64: