Public/Private DNS resolution over VPN

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I have a private NAT internal network with private internal DNS server and I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using Microsoft VPN
client, they are not able to get the private internal IP address of any
publicly available resource. Because the internal network does not know how
to route public IP addresses, these users are not able to connect to the
Exchange server or internal web sites. Does anyone have a suggestion as to
how to resolve this issue? This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to use the
local default gateway. If the address is not listed in the public DNS, then
the private DNS address is resolved from the internal DNS server.
 
RichWhit said:
I have a private NAT internal network with private internal DNS server and I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using Microsoft VPN
client, they are not able to get the private internal IP address of any
publicly available resource. Because the internal network does not know how
to route public IP addresses, these users are not able to connect to the
Exchange server or internal web sites. Does anyone have a suggestion as to
how to resolve this issue?

You are mingling a DNS problem with a routing problem -- such are almost
totally separate. Routing should be solved first, then DNS made to work.

If you have the "same zone (name)" inside as outside this is termed "Shadow
DNS" (or split DNS" and requires that you MANUALLY duplicate all useful
external resources into the internal version of the zone.

This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to use the
local default gateway. If the address is not listed in the public DNS, then
the private DNS address is resolved from the internal DNS server.

Tell us very explicitly how this routes -- do a lot of "tracert" using IP
addresses and focus on where things go wrong (wrong initial router,
stuck in the VPN, wherever.)

Then lets figure out the DNS if it is still broken after you configure you
shadow DNS (if that is what you have) corrrectly.
 
I do maintain the same dns zones internally and externally. The external dnz
zones have the public IP addresses that need to be accessed publicly and the
internal dns zone has the private internal IP addresses listed for the all
internal resources. There is a NAT translation done at the firewall. If a
user is connected to the internal network via the VPN server which is located
behind the firewall, only private IP address can be used. Some users do not
get the private IP address from the internal DNS server, but rather get the
public IP address from their ISP dns server. If the resource is not listed
in the public DNS then the client gets the private IP address from the
private DNS server. How can I force name resolution to use only the internal
private dns server provided through the DHCP settings projected through the
VPN server to the VPN client.

Herb Martin said:
RichWhit said:
I have a private NAT internal network with private internal DNS server and I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using Microsoft VPN
client, they are not able to get the private internal IP address of any
publicly available resource. Because the internal network does not know how
to route public IP addresses, these users are not able to connect to the
Exchange server or internal web sites. Does anyone have a suggestion as to
how to resolve this issue?

You are mingling a DNS problem with a routing problem -- such are almost
totally separate. Routing should be solved first, then DNS made to work.

If you have the "same zone (name)" inside as outside this is termed "Shadow
DNS" (or split DNS" and requires that you MANUALLY duplicate all useful
external resources into the internal version of the zone.

This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to use the
local default gateway. If the address is not listed in the public DNS, then
the private DNS address is resolved from the internal DNS server.

Tell us very explicitly how this routes -- do a lot of "tracert" using IP
addresses and focus on where things go wrong (wrong initial router,
stuck in the VPN, wherever.)

Then lets figure out the DNS if it is still broken after you configure you
shadow DNS (if that is what you have) corrrectly.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
RichWhit said:
I do maintain the same dns zones internally and externally. The external dnz
zones have the public IP addresses that need to be accessed publicly and the
internal dns zone has the private internal IP addresses listed for the all
internal resources.

Makes sense, but the INTERNAL must also have all of the external
records (and addresses) for any resources you wish the internal users
to contact.
There is a NAT translation done at the firewall. If a
user is connected to the internal network via the VPN server which is located
behind the firewall, only private IP address can be used.

Why? In theory, it can come with private and go back out through the
NAT to acceptable Internet locations (e.g., Microsoft.com) IF you have
the routing setup properly.

Likely you would prefer to use an internal address for any resource
that exists with both internal and external addresses.
Some users do not
get the private IP address from the internal DNS server, but rather get the
public IP address from their ISP dns server. If the resource is not listed
in the public DNS then the client gets the private IP address from the
private DNS server.

No, you cannot expect a client (or ordinary forwarding/recursing DNS server)
to check "two DNS servers" if the first one fails to resolve or gives out
unusable
addresses.

DNS clients ONLY check one DNS system (one working DNS server) and that
one must resolve everything that is needed by that client.

People commonly try to put in Preferred and Alternate DNS DNS servers from
different DNS server "sets" in the mistaken belief that clients will keep
checking;
they will not.

How can I force name resolution to use only the internal
private dns server provided through the DHCP settings projected through the
VPN server to the VPN client.

Normally an RRAS client (VPN or RRAS) uses the DNS server (and WINS server
and Default Gateways) from the RRAS server -- these are given priority WHILE
the connection is in place. When the connection is dropped the interface
(VPN/RAS)
specific stuff if removed and the machine goes back to using the normal NIC
property stuff it has configured.

You can test such things by looking at "ipconfig /all" and by using programs
(while
connected) like "Nslookup TARGET" to see which is the "current default" DNS
server.

You can also use "Nslookup TARGET IP_SPECIFIC_DNS_SERVER" to see
if this would get you a different answer.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Herb Martin said:
RichWhit said:
I have a private NAT internal network with private internal DNS server
and
I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using
Microsoft
VPN
client, they are not able to get the private internal IP address of any
publicly available resource. Because the internal network does not
know
how
to route public IP addresses, these users are not able to connect to the
Exchange server or internal web sites. Does anyone have a suggestion
as
to
how to resolve this issue?

You are mingling a DNS problem with a routing problem -- such are almost
totally separate. Routing should be solved first, then DNS made to work.

If you have the "same zone (name)" inside as outside this is termed "Shadow
DNS" (or split DNS" and requires that you MANUALLY duplicate all useful
external resources into the internal version of the zone.

This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to use the
local default gateway. If the address is not listed in the public
DNS,
then
the private DNS address is resolved from the internal DNS server.

Tell us very explicitly how this routes -- do a lot of "tracert" using IP
addresses and focus on where things go wrong (wrong initial router,
stuck in the VPN, wherever.)

Then lets figure out the DNS if it is still broken after you configure you
shadow DNS (if that is what you have) corrrectly.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
It is your opinion that I should publish the public and private IP address in
the internal DNS zone?

Herb Martin said:
RichWhit said:
I do maintain the same dns zones internally and externally. The external dnz
zones have the public IP addresses that need to be accessed publicly and the
internal dns zone has the private internal IP addresses listed for the all
internal resources.

Makes sense, but the INTERNAL must also have all of the external
records (and addresses) for any resources you wish the internal users
to contact.
There is a NAT translation done at the firewall. If a
user is connected to the internal network via the VPN server which is located
behind the firewall, only private IP address can be used.

Why? In theory, it can come with private and go back out through the
NAT to acceptable Internet locations (e.g., Microsoft.com) IF you have
the routing setup properly.

Likely you would prefer to use an internal address for any resource
that exists with both internal and external addresses.
Some users do not
get the private IP address from the internal DNS server, but rather get the
public IP address from their ISP dns server. If the resource is not listed
in the public DNS then the client gets the private IP address from the
private DNS server.

No, you cannot expect a client (or ordinary forwarding/recursing DNS server)
to check "two DNS servers" if the first one fails to resolve or gives out
unusable
addresses.

DNS clients ONLY check one DNS system (one working DNS server) and that
one must resolve everything that is needed by that client.

People commonly try to put in Preferred and Alternate DNS DNS servers from
different DNS server "sets" in the mistaken belief that clients will keep
checking;
they will not.

How can I force name resolution to use only the internal
private dns server provided through the DHCP settings projected through the
VPN server to the VPN client.

Normally an RRAS client (VPN or RRAS) uses the DNS server (and WINS server
and Default Gateways) from the RRAS server -- these are given priority WHILE
the connection is in place. When the connection is dropped the interface
(VPN/RAS)
specific stuff if removed and the machine goes back to using the normal NIC
property stuff it has configured.

You can test such things by looking at "ipconfig /all" and by using programs
(while
connected) like "Nslookup TARGET" to see which is the "current default" DNS
server.

You can also use "Nslookup TARGET IP_SPECIFIC_DNS_SERVER" to see
if this would get you a different answer.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Herb Martin said:
I have a private NAT internal network with private internal DNS server and
I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using Microsoft
VPN
client, they are not able to get the private internal IP address of any
publicly available resource. Because the internal network does not know
how
to route public IP addresses, these users are not able to connect to the
Exchange server or internal web sites. Does anyone have a suggestion as
to
how to resolve this issue?

You are mingling a DNS problem with a routing problem -- such are almost
totally separate. Routing should be solved first, then DNS made to work.

If you have the "same zone (name)" inside as outside this is termed "Shadow
DNS" (or split DNS" and requires that you MANUALLY duplicate all useful
external resources into the internal version of the zone.


This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to use the
local default gateway. If the address is not listed in the public DNS,
then
the private DNS address is resolved from the internal DNS server.

Tell us very explicitly how this routes -- do a lot of "tracert" using IP
addresses and focus on where things go wrong (wrong initial router,
stuck in the VPN, wherever.)

Then lets figure out the DNS if it is still broken after you configure you
shadow DNS (if that is what you have) corrrectly.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
RichWhit said:
It is your opinion that I should publish the public and private IP address in
the internal DNS zone?

No, not exactly. It is my advice to publish all Private Addresses
you wish to in the internal (version of the) zone, and to also publish
only those public addresses there which will not conflict.

Publishing a public address is of course unnecessary if the particular
resource is not ever needed by internal users, but other than that publish
it -- BUT ONLY if it is not already published via an internal address.

The goal is to give the internal users (via the Internal DNS) ALL of
the resources available with internal addresses, and then supplement
this by listing any public resources only available through the public
IP.

After that, the problem boils down to routing (and perhaps firewall
filters.)

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
Herb Martin said:
RichWhit said:
I do maintain the same dns zones internally and externally. The
external
dnz
zones have the public IP addresses that need to be accessed publicly
and
the
internal dns zone has the private internal IP addresses listed for the all
internal resources.

Makes sense, but the INTERNAL must also have all of the external
records (and addresses) for any resources you wish the internal users
to contact.
There is a NAT translation done at the firewall. If a
user is connected to the internal network via the VPN server which is located
behind the firewall, only private IP address can be used.

Why? In theory, it can come with private and go back out through the
NAT to acceptable Internet locations (e.g., Microsoft.com) IF you have
the routing setup properly.

Likely you would prefer to use an internal address for any resource
that exists with both internal and external addresses.
Some users do not
get the private IP address from the internal DNS server, but rather
get
the
public IP address from their ISP dns server. If the resource is not listed
in the public DNS then the client gets the private IP address from the
private DNS server.

No, you cannot expect a client (or ordinary forwarding/recursing DNS server)
to check "two DNS servers" if the first one fails to resolve or gives out
unusable
addresses.

DNS clients ONLY check one DNS system (one working DNS server) and that
one must resolve everything that is needed by that client.

People commonly try to put in Preferred and Alternate DNS DNS servers from
different DNS server "sets" in the mistaken belief that clients will keep
checking;
they will not.

How can I force name resolution to use only the internal
private dns server provided through the DHCP settings projected
through
the
VPN server to the VPN client.

Normally an RRAS client (VPN or RRAS) uses the DNS server (and WINS server
and Default Gateways) from the RRAS server -- these are given priority WHILE
the connection is in place. When the connection is dropped the interface
(VPN/RAS)
specific stuff if removed and the machine goes back to using the normal NIC
property stuff it has configured.

You can test such things by looking at "ipconfig /all" and by using programs
(while
connected) like "Nslookup TARGET" to see which is the "current default" DNS
server.

You can also use "Nslookup TARGET IP_SPECIFIC_DNS_SERVER" to see
if this would get you a different answer.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
:

I have a private NAT internal network with private internal DNS
server
and
I
have a public DNS hosted for my publicly available servers and services.
When some users connect to the private internal network using Microsoft
VPN
client, they are not able to get the private internal IP address
of
any
publicly available resource. Because the internal network does
not
know
how
to route public IP addresses, these users are not able to connect
to
the
Exchange server or internal web sites. Does anyone have a
suggestion
as
to
how to resolve this issue?

You are mingling a DNS problem with a routing problem -- such are almost
totally separate. Routing should be solved first, then DNS made to work.

If you have the "same zone (name)" inside as outside this is termed "Shadow
DNS" (or split DNS" and requires that you MANUALLY duplicate all useful
external resources into the internal version of the zone.


This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to
use
the
local default gateway. If the address is not listed in the public DNS,
then
the private DNS address is resolved from the internal DNS server.

Tell us very explicitly how this routes -- do a lot of "tracert"
using
IP
addresses and focus on where things go wrong (wrong initial router,
stuck in the VPN, wherever.)

Then lets figure out the DNS if it is still broken after you
configure
you
shadow DNS (if that is what you have) corrrectly.

--
Herb Martin, MCSE, MVP
Accelerated MCSE
http://www.LearnQuick.Com
[phone number on web site]
 
In RichWhit <[email protected]> stated, which I then commented
I have a private NAT internal network with private internal DNS
server and I have a public DNS hosted for my publicly available
servers and services. When some users connect to the private internal
network using Microsoft VPN client, they are not able to get the
private internal IP address of any publicly available resource.
Because the internal network does not know how to route public IP
addresses, these users are not able to connect to the Exchange server
or internal web sites. Does anyone have a suggestion as to how to
resolve this issue? This is only an issue for some users. The
clients are configured with default VPN settings that stipulate to
use the local default gateway. If the address is not listed in the
public DNS, then the private DNS address is resolved from the
internal DNS server.

Curious Rich, what is the internal private range? Is it 192.168.0.0/24?

Reason I ask is usually for the most case in a same internal/external zone
name (split-brain, split-zone, among the many names for it), usually will
just work with VPNs. The Microsoft VPN client, as well as vendor specific
clients, will use the VPN connection as the default connection thus using
the DHCP assigned IP and options (DNS, WINS, etc) for connectivity. If the
private addresses are in the private server, it will resolve to that first
and will attempt to connect to that first.

My main client is setup that way. It was done prior to my involvment,
otherwise I would have chosen a subdomain namespace for the AD zone, such as
corp.domain.com.

One problem I've seen is when the internal IP range is the one mentioned
above, and the user's system they are connecting from at home is of the same
subnet behind their own little NAT device. This will cause major problems
with resolution.

Another method I've seen to combat similar VPN issues is to create a batch
file to populate their hosts files with the pertinent DC and OWA name and
IPs

If it is just happening on "some" users, the first thing I would look at is
their IP range at home if it is the same as the corp network.


--
Regards,
Ace

Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services
Infinite Diversities in Infinite Combinations.
=================================
 
Back
Top